Re: Updates to linux-firmware
Hello there Mark, thanks for your email, and for the followup ping; weeks are well-filled with $job, baby and other involvements. Regarding firmware-nonfree updates, I have related my last-years' experience on d-devel: https://lists.debian.org/msgid-search/2390124.3VsfAaAtOV@turnagra I insist: I am absolutely not implying that Ben is doing anything wrong; I just observed that he was mostly alone in a bottleneck position for that package. What I did back then to try to help getting the firmware package in better shape was to dive in the (complex) packaging and try to produce "ready-to- merge" merge-requests for new upstream releases, fixes, etc, then pinging Ben at (what I considered) reasonable intervals. I see that Diederik (CC'ed) has started to do the same for recent versions. The package is complex and a mined land of legal concerns, the upstream repo needs repacking, and the (upstream & debian/) repositories are split; I have not found this a very pleasant experience, sadly. And again; no-one to blame here: there _is_ tooling to help, and immense work has been put towards making this manageable! I'm merely saying it's not a matter of running "debian/rules get-new-upstream" at all. From where I sit (that is: I only modestly contributed in the past, and cannot commit to much these days), there are two angles to address: A) lift the bottleneck: there needs to be more Debian Developers confident to comment and merge MRs, and then upload. B) regular commitment: I feel it would be easier to get regular updates merged, rather than doing the huge batch shortly before release; that would also appease the tensions that many probably feel when they get new hardware but no available package. As to how I can get involved in any of the above; I can't reasonably add this to my plate these days (and would rather _not do_, than commit to do and fail). But I wonder if some financial sponsorship (if Lenovo and others would be open to something like that) could help, via Freexian for example (disclaimer: not for me to do it; I'm not a Freexian person). I'd be concerned that this would only solve B above though. It would feel like a 1-2 hours job / week. I hope the above helps you navigate that question, and that it helps the situation in general. Best, Didier Le vendredi, 26 avril 2024, 20.35:41 h CEST Mark Pearson a écrit : > Hi Didier & Ben, > > I hope all is well. > I wanted to check in with you guys, as with the new 2024 platforms coming > out there are some updates to linux-firmware - for CPU, GPU, Wifi, > Bluetooth, etc devices > > I checked and it looked like firmware-nonfree and it hadn't been updated > since last year - and I wondered if that is something I can help with? I'd > like to make sure the Debian experience on this years platforms is good > out-of-the-box. > > Let me know if that would be helpful, and any pointers on how best to > contribute and be useful > > Thanks > Mark > > PS - in case anyone notices, I've mothballed my old markpear...@lenovo.com > address because the Lenovo outlook servers there became horribly unusable. > I am using my personal domain for open source collaboration instead. I > still have access to that address (if anybody wants to check I am who I say > I am) and am still employed at Lenovo (if that makes any difference to > anything) -- OdyX
Bug#1029046: Wayland session doesn't get back to life post-suspend
Control: tags -1 +patch -help
Control: clone -1 -2
Control: retitle -2 Thinkpad AMD: amd_pmc module is required for correct s0ix
(Windows mode) suspend
Control: severity -2 important
Hello there,
My understanding is that there are two distinct bugs here; hereby splitting
to make this clearer.
* Original bug, as retitled by Salvatore; S3 suspend is broken on some AMD
Ryzens. This is fixed by this patch queue, also attached.
https://gitlab.freedesktop.org/superm1/linux/-/commits/mlimonci/rhbz-2162013-gitlab-2357-v4/
In the BIOS, "S3" is "Linux mode" for suspend.
* While investigating this; it turns out modern kernels can also suspend
on s0ix "Windows mode", but this _requires_ the `amd_pmc` module, which
is not loaded automatically, but it really should. This doesn't look
like an upstream bug, but rather a Debian one.
As this only shows on Laptops with a "Windows mode" BIOS configuration
(in a box that also shows "Linux mode"), I think it's reasonable to see
this as a bug of only "important" level (even though not resuming from
suspend is _bad_).
I don't think we have seen a patch to fix this one yet though.
Best,
OdyX
Index: linux/drivers/gpio/gpiolib-acpi.c
===
--- linux.orig/drivers/gpio/gpiolib-acpi.c
+++ linux/drivers/gpio/gpiolib-acpi.c
@@ -361,7 +361,7 @@ err:
}
static bool acpi_gpio_irq_is_wake(struct device *parent,
- struct acpi_resource_gpio *agpio)
+ const struct acpi_resource_gpio *agpio)
{
unsigned int pin = agpio->pin_table[0];
@@ -754,7 +754,7 @@ static int acpi_populate_gpio_lookup(str
lookup->info.pin_config = agpio->pin_config;
lookup->info.debounce = agpio->debounce_timeout;
lookup->info.gpioint = gpioint;
- lookup->info.wake_capable = agpio->wake_capable == ACPI_WAKE_CAPABLE;
+ lookup->info.wake_capable = acpi_gpio_irq_is_wake(&lookup->info.adev->dev, agpio);
/*
* Polarity and triggering are only specified for GpioInt
@@ -1080,7 +1080,7 @@ int acpi_dev_gpio_irq_wake_get_by(struct
dev_dbg(&adev->dev, "IRQ %d already in use\n", irq);
}
- if (wake_capable)
+ if (wake_capable && acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0)
*wake_capable = info.wake_capable;
return irq;
@@ -1599,6 +1599,19 @@ static const struct dmi_system_id gpioli
.ignore_interrupt = "AMDI0030:00@18",
},
},
+ {
+ /*
+ * Spurious wakeups from TP_ATTN# pin
+ * Found in BIOS 1.7.8
+ * https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1720627
+ */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+ },
+ .driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+ .ignore_wake = "ELAN0415:00@9",
+ },
+ },
{} /* Terminating entry */
};
Index: linux/drivers/pinctrl/pinctrl-amd.c
===
--- linux.orig/drivers/pinctrl/pinctrl-amd.c
+++ linux/drivers/pinctrl/pinctrl-amd.c
@@ -365,6 +365,7 @@ static void amd_gpio_dbg_show(struct seq
} else {
debounce_enable = " ∅";
+time = 0;
}
snprintf(debounce_value, sizeof(debounce_value), "%u", time * unit);
seq_printf(s, "debounce %s (🕑 %sus)| ", debounce_enable, debounce_value);
signature.asc
Description: This is a digitally signed message part.
Bug#1028451: 2nd DisplayPort doesn't get video
Control: tags -1 +patch
Le vendredi, 20 janvier 2023, 21.38:42 h CET Salvatore Bonaccorso a écrit :
> There is the patchset currently asked for inclusion at
> https://lore.kernel.org/stable/20230119235200.441386-1-harry.wentl...@amd.co
> m/T/#m3b5b3616eac750cfd7c9bd00ac1cf95006a6aeec which is for addressing this
> issue.
Indeed. I can confirm this fixes my issue with the attached patch on top of
6.1.7-1, which is all 4 patches from :
https://gitlab.freedesktop.org/hwentland/linux/-/commits/mst_regression_6.1
aka:
https://gitlab.freedesktop.org/hwentland/linux/-/compare/
21e996306a6afaae88295858de0ffb8955173a15...1521e9dcb431f31c15a0256cb619b09cca3efc4e?
from_project_id=12209&straight=false
I hope this can either get to 6.1 stable, or be backported / carried over by
Debian! Happy to MR this if it makes sense!
Best,
OdyXdiff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index dacad8b85963..fbc89129e7de 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9399,6 +9399,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
struct drm_connector_state *old_con_state, *new_con_state;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct drm_dp_mst_topology_mgr *mgr;
+ struct drm_dp_mst_topology_state *mst_state;
struct drm_plane *plane;
struct drm_plane_state *old_plane_state, *new_plane_state;
enum dc_status status;
@@ -9654,6 +9656,28 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
lock_and_validation_needed = true;
}
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ /* set the slot info for each mst_state based on the link encoding format */
+ for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+ struct amdgpu_dm_connector *aconnector;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter iter;
+ u8 link_coding_cap;
+
+ drm_connector_list_iter_begin(dev, &iter);
+ drm_for_each_connector_iter(connector, &iter) {
+ if (connector->index == mst_state->mgr->conn_base_id) {
+aconnector = to_amdgpu_dm_connector(connector);
+link_coding_cap = dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+drm_dp_mst_update_slots(mst_state, link_coding_cap);
+
+break;
+ }
+ }
+ drm_connector_list_iter_end(&iter);
+ }
+#endif
+
/**
* Streams and planes are reset when there are changes that affect
* bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index f72c013d3a5b..16623f73ddbe 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -120,23 +120,50 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
}
static void
-fill_dc_mst_payload_table_from_drm(struct drm_dp_mst_topology_state *mst_state,
- struct amdgpu_dm_connector *aconnector,
+fill_dc_mst_payload_table_from_drm(struct dc_link *link,
+ bool enable,
+ struct drm_dp_mst_atomic_payload *target_payload,
struct dc_dp_mst_stream_allocation_table *table)
{
struct dc_dp_mst_stream_allocation_table new_table = { 0 };
struct dc_dp_mst_stream_allocation *sa;
- struct drm_dp_mst_atomic_payload *payload;
+ struct link_mst_stream_allocation_table copy_of_link_table =
+ link->mst_stream_alloc_table;
+
+ int i;
+ int current_hw_table_stream_cnt = copy_of_link_table.stream_count;
+ struct link_mst_stream_allocation *dc_alloc;
+
+ /* TODO: refactor to set link->mst_stream_alloc_table directly if possible.*/
+ if (enable) {
+ dc_alloc =
+ ©_of_link_table.stream_allocations[current_hw_table_stream_cnt];
+ dc_alloc->vcp_id = target_payload->vcpi;
+ dc_alloc->slot_count = target_payload->time_slots;
+ } else {
+ for (i = 0; i < copy_of_link_table.stream_count; i++) {
+ dc_alloc =
+ ©_of_link_table.stream_allocations[i];
+
+ if (dc_alloc->vcp_id == target_payload->vcpi) {
+dc_alloc->vcp_id = 0;
+dc_alloc->slot_count = 0;
+break;
+ }
+ }
+ ASSERT(i != copy_of_link_table.stream_count);
+ }
/* Fill payload info*/
- list_for_each_entry(payload, &mst_state->payloads, next) {
- if (payload->delete)
- continue;
-
- sa = &new_table.stream_allocations[new_table.stream_count];
- sa->slot_count = payload->time_slots;
- sa->vcp_id = payload->vcpi;
- new_table.stream_count++;
+ for (i = 0; i < MAX_CONTROLLER_NUM; i++) {
+ dc_alloc =
+ ©_of_link_table.stream_allocations[i];
+ if (dc_alloc->vcp_id > 0 && dc_alloc->slot_count > 0) {
+ sa = &new_table.stream_allocations[new_table.stream_count];
+ sa->slot_count = dc_alloc->slot_count;
+ sa->vcp_id = dc_alloc->vcp_id;
+ new_table.stream_count++;
+ }
}
/* Overwrite the old table */
@@ -185,7 +212,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
* AUX message
Bug#1029046: Wayland session doesn't get back to life post-suspend
Control: retitle -1 Thinkpad: amd_pmc module required for on 6.1 for correct suspend Le mardi, 17 janvier 2023, 22.53:54 h CET Didier 'OdyX' Raboud a écrit : > Le mardi, 17 janvier 2023, 15.32:37 h CET Diederik de Haas a écrit : > > On Monday, 16 January 2023 22:33:05 CET Didier 'OdyX' Raboud wrote: > > > This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't > > > light up", so feel free to close the bug; I'll test if I get the same > > > symptoms on an unpatched kernel anyway :-) > > > > If this issue doesn't occur with the unpatched kernel, that would be VERY > > important extra information! > > https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1724186 may be > > the same or similar finding? > > > > If that issue doesn't occur with the unpatched kernel, could you add your > > finding to that upstream/forwarded issue? > > Now that I got my kernel build in place; I can actually confirm that: > > On my Thinkpad X13 Gen 2a, without any dongle, hub or docking station (on > battery), with a KDE Plasma Wayland session: > > * 6.0.0-6-amd64 (6.0.12-1) > suspends and resumes correctly > * 6.1.0-1-amd64 (6.1.4-1, unpatched) > doesn't finish suspending > * 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, not patched) > doesn't finish suspending > * 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, patched), > doesn't finish suspending > > All three 6.1 kernels (whether patched or not) don't bring the laptop to the > suspended state (power led 'breathing', fans off), but it's kept in an "on" > state (power led on, fans on), from which I found that I *can* wake the > laptop up by short-pressing the power button; the screens gets back to life > and show my lockscreen. But from there, I can't move the mouse nor do > anything else. Alt-SysRq-r + ctrl-alt-f2 give me a tty, but any comeback to > tty1 only blank (not even a blank screen, just a freeze). > > This seems to point to a quite severe regression in amdgpu or other amd- > related code; I can't suspend-and-resume the laptop anymore on any 6.1 > kernel, on battery, without anything attached to it. > > I'll forward the above findings to the bug you pointed to, hoping it could > help upstream too! OK. I've gone and done this: https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1727281 It turns out to get suspend to work, the `amd_pmc` module needs to be enabled (_AND_ the BIOS needs to have the "Sleep State" toggled to Windows (from Linux). I _think_ Debian should make sure amd_pmc is loaded on (all?) modern AMD laptops. I have no idea (yet) what the mechanism to make this happen is though. -- OdyX
Bug#1029046: Wayland session doesn't get back to life post-suspend
Control: found -1 6.1.6-1 Control: found -1 6.1.4-1 Control: severity -1 serious Hello there, Le mardi, 17 janvier 2023, 15.32:37 h CET Diederik de Haas a écrit : > On Monday, 16 January 2023 22:33:05 CET Didier 'OdyX' Raboud wrote: > > This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't > > light up", so feel free to close the bug; I'll test if I get the same > > symptoms on an unpatched kernel anyway :-) > > If this issue doesn't occur with the unpatched kernel, that would be VERY > important extra information! > https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1724186 may be the > same or similar finding? > > If that issue doesn't occur with the unpatched kernel, could you add your > finding to that upstream/forwarded issue? Now that I got my kernel build in place; I can actually confirm that: On my Thinkpad X13 Gen 2a, without any dongle, hub or docking station (on battery), with a KDE Plasma Wayland session: * 6.0.0-6-amd64 (6.0.12-1) suspends and resumes correctly * 6.1.0-1-amd64 (6.1.4-1, unpatched) doesn't finish suspending * 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, not patched) doesn't finish suspending * 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, patched), doesn't finish suspending All three 6.1 kernels (whether patched or not) don't bring the laptop to the suspended state (power led 'breathing', fans off), but it's kept in an "on" state (power led on, fans on), from which I found that I *can* wake the laptop up by short-pressing the power button; the screens gets back to life and show my lockscreen. But from there, I can't move the mouse nor do anything else. Alt-SysRq-r + ctrl-alt-f2 give me a tty, but any comeback to tty1 only blank (not even a blank screen, just a freeze). This seems to point to a quite severe regression in amdgpu or other amd- related code; I can't suspend-and-resume the laptop anymore on any 6.1 kernel, on battery, without anything attached to it. I'll forward the above findings to the bug you pointed to, hoping it could help upstream too! Best, OdyX
Bug#1028451: 2nd DisplayPort doesn't get video
Hello Salvatore, 17 janvier 2023 07:14 "Salvatore Bonaccorso" a écrit: > I will bite the bullet (taking full responsibility for it if > necessary, don't blame the other kernel team members) and ask here now > the release team: Can we let linux 6.1.4-1 despite the RC bug > reported, migrate to testing, so we can move on to 6.1.y? Let's keep > the bug as RC severity. I'm currently working on uploading as well > 6.1.6 or 6.1.7 (depending on the timing) further after that to > unstable. Unfortuantely there is still not a solution to address > #1028451 but will contain other important fixes (including security > ones). > > Thank you for considering it, > > Odyx, I feel sorry, this will knowingly impact your and others! No problem; such is the life on the unstable/testing edge. I'll keep a 6.0.0-6 kernel around, and will keep testing the most recent kernels; as well as report back if these help. Best, OdyX
Bug#1029046: Wayland session doesn't get back to life post-suspend
Package: linux-image-6.1.0-1-amd64 Version: 6.1.4-1 Severity: important Hello there, this is a regression from 6.0.0 too; after post-suspend wakeup, my plasma wayland session stays frozen; the two DisplayPort screens light up, backgrounds are shown, but the mouse doesn't move, nothing works. I'm reportbug'ging this from a SysRQ-R, Ctrl-Alt-F2 text tty. >From cursory dmesg reading, it seems amdgpu has an "IB test failed" _before_ kernel suspend. This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't light up", so feel free to close the bug; I'll test if I get the same symptoms on an unpatched kernel anyway :-) Best, OdyX -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-6.1.0-1-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.142 ii kmod30+20221128-1 ii linux-base 4.9 Versions of packages linux-image-6.1.0-1-amd64 recommends: ii apparmor 3.0.8-1 ii firmware-linux-free 20200122-1 Versions of packages linux-image-6.1.0-1-amd64 suggests: pn debian-kernel-handbook ii extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1 ii grub-efi-amd64 2.06-7 pn linux-doc-6.1
Bug#1028451: 2nd DisplayPort doesn't get video
Hello there, I finally managed to test https://github.com/archlinux/linux/commit/7c4fed4d2afd27d7acb8835f8e79f49c99c03cdf.patch (which is a revert of 4d07b0bc403403438d9cf88450506240c5faf92f) … on top of 6.1.4-1. I can confirm (without looking into any code-related details), that the two of my DisplayPort-connected screens light up and work correctly. (The "first" external screen is connected with a DisplayPort-DVI converter; that one always worked; the "second" is connected directly via DisplayPort, which didn't work on unpatched 6.1.4) 14 janvier 2023 17:52 "Diederik de Haas" a écrit: > On Saturday, 14 January 2023 16:30:05 CET Salvatore Bonaccorso wrote: >> On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: >> On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: >>> Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked >>> >>> upstream here: >>> https://gitlab.freedesktop.org/drm/amd/-/issues/2171 >> >> Thanks! About an hour ago the suggested fix was to revert commit >> 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 >> >> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html# >> s4.2.2 describes a procedure to build a kernel with the proposed patch >> (attached). >> >> OdyX: Can you try to see whether that resolves the issue? >> >> Should we keep 6.1.y based kernel out of testing until this is clear? >> As we aim though to have 6.1.y into bookworm I would see it as more >> preferable to get 6.1.4 in for testing, we will need to followup as >> well soonish with another interation for e.g. for fixing >> CVE-2023-0266. > > As CVE-2023-0266 is fixed in 6.1.6, I'd suggest to upload that now, which I > believe is ready to be uploaded already. > That should keep 6.1.y out of testing for a few more days. > >> Now if it turns out that this is the same issue as the referenced >> upstream, reverting I think we only should really revert the commit if >> that's queued up for 6.1. There is currently some furhter discussion >> on >> https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com >> /T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40 >> >> Given the size of the revert, there is as well a chance to re-break >> other parts. So preferring to closely follow upstream here, whatever >> the decision will be. > > Agreed. > > I asked 'OdyX' to test the revert to make sure it would indeed fix *this* > issue, IOW what I consider standard bug triaging. > > But even Daniel Vetter has SERIOUS 'issues' with the revert, next to the other > people who weren't happy about it. So *I* wouldn't suggest applying it to > Debian (although I don't think my opinion should have much weight). > > As for letting this bug _continue_ to prevent a migration, ie keep the RC > status, I'm against it and for downgrading it to 'important'. > You could opt to add a NEWS item to warn people about this potential issue. > > But the original report is about the *2nd* DisplayPort being 'broken'. > > On zaterdag 14 januari 2023 17:04:52 CET you wrote: > >> Basically this issue breaks all usage of Displayport MST on amdgpu systems. >> Which roughly translates to breaking external monitors for everyone using >> an USB-C docks with multiple display outputs (which is pretty common these >> days) on AMD laptops. As well as those like myself who daisy-chain display >> port monitors with an amdgpu using graphics card. > > I understand that would be annoying for you, but I don't think that it would > affect the majority of our users. Hrm. More and more laptops come with usb-c only, and dongles/docks become more and more common. It's clearly a serious regression, as such setups "just worked" with 6.0. Best, OdyX
Bug#1028451: 2nd DisplayPort doesn't get video
Hello there, It's really time-consuming to download, reboot, wait cryptsetup prompt, fail, reboot, wait cryptsetup prompt, type long passphrase, log in account, dpkg -i, reboot, rinse repeat. Anyway, I can confirm that on my Lenovo X13 AMD; * 6.1~rc3+1~exp1 doesn't boot until the cryptsetup prompt * 6.1~rc5+1~exp1 doesn't boot until the cryptsetup prompt * 6.1~rc6+1~exp1 doesn't boot until the cryptsetup prompt * 6.1~rc7+1~exp1 boots until the cryptsetup prompt, but the culprit screen doesn't get anything So it seems the issue was already there in 6.1~rc7+1~exp1, but I can't rewind further. Hope that helps! OdyX 11 janvier 2023 10:04 "Diederik de Haas" a écrit: > On Wednesday, 11 January 2023 08:33:29 CET Didier 'OdyX' Raboud wrote: > >> Package: src:linux >> Version: 6.1.4-1 >> Severity: serious >> >> Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking >> Station doesn't get any output. > > Can you try the previous versions of the 6.1.x series which you can get via > snapshot.debian.org? I recommend to start with the first 6.1-rcX version. > > A `git bisect` is the best way to figure out what caused it, but the above > procedure is the quickest way to narrow down the search space.
Bug#1028451: 2nd DisplayPort doesn't get video
Package: src:linux Version: 6.1.4-1 Severity: serious Hello there, Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking Station doesn't get any output. It is _seen_ as connected by the screen, but apparently gets no video signal (or just blank). This is clearly a regression from 6.0.0-6 where this was working. I'm quite confident this is a kernel-level change (and not X11 or Plasma) as this already appears clearly at cryptsetup password prompt (which usually goes to all outputs, but not on 6.1.0-1 which only displays it on the laptop screen and the 1st connected DisplayPort. Happy to help solve this. Best, OdyX -- Package-specific info: ** Version: Linux version 6.1.0-1-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) ** Command line: BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 root=/dev/mapper/turnagra--vg-root ro quiet splash cgroup_enable=memory apparmor=1 security=apparmor ** Tainted: W (512) * kernel issued warning ** Kernel log: [ 15.343546] input: HD-Audio Generic Headphone as /devices/pci:00/:00:08.1/:05:00.6/sound/card4/input38 [ 15.443246] usbcore: registered new interface driver btusb [ 15.481320] bluetooth hci0: firmware: direct-loading firmware mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin [ 15.493335] intel_rapl_common: Found RAPL domain package [ 15.493340] intel_rapl_common: Found RAPL domain core [ 15.499969] mt7921e :03:00.0: enabling device ( -> 0002) [ 15.518411] mt7921e :03:00.0: ASIC revision: 79610010 [ 15.602835] mt7921e :03:00.0: firmware: direct-loading firmware mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin [ 15.602842] mt7921e :03:00.0: HW/SW Version: 0x8a108a10, Build Time: 20221109110918a [ 15.603213] Bluetooth: hci0: Device setup in 121459 usecs [ 15.603217] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [ 15.614235] mt7921e :03:00.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin [ 15.614240] mt7921e :03:00.0: WM Firmware Version: 01, Build Time: 20221109111005 [ 15.654966] mt7921e :03:00.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin [ 15.676225] EXT4-fs (nvme0n1p2): mounting ext2 file system using the ext4 subsystem [ 15.677063] EXT4-fs (nvme0n1p2): mounted filesystem without journal. Quota mode: none. [ 15.679393] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Quota mode: none. [ 15.679984] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Quota mode: none. [ 15.689038] systemd-journald[673]: Received client request to flush runtime journal. [ 15.692904] systemd-journald[673]: File /var/log/journal/554675a9a7254eeea535d3d6aa31a8a6/system.journal corrupted or uncleanly shut down, renaming and replacing. [ 15.849074] audit: type=1400 audit(1673421894.663:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=980 comm="apparmor_parser" [ 15.849408] audit: type=1400 audit(1673421894.663:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=966 comm="apparmor_parser" [ 15.849475] audit: type=1400 audit(1673421894.663:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oosplash" pid=979 comm="apparmor_parser" [ 15.849517] audit: type=1400 audit(1673421894.663:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="torbrowser_tor" pid=974 comm="apparmor_parser" [ 15.849866] audit: type=1400 audit(1673421894.663:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=969 comm="apparmor_parser" [ 15.849871] audit: type=1400 audit(1673421894.663:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=969 comm="apparmor_parser" [ 15.849949] audit: type=1400 audit(1673421894.663:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=977 comm="apparmor_parser" [ 15.849954] audit: type=1400 audit(1673421894.663:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=977 comm="apparmor_parser" [ 15.849957] audit: type=1400 audit(1673421894.663:12): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=977 comm="apparmor_parser" [ 15.851055] audit: type=1400 audit(1673421894.667:13): apparmor="STATUS" operation="profile_load" profile="unconfined" name="system_tor" pid=972 comm="apparmor_parser" [ 16.466830] mt7921e :03:00.0 wlp3s0: renamed from wlan0 [ 16.789424] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 16.789428] Bluetooth: BNEP filters: protocol multicast [ 16.789433] Bluetooth: BNEP socket layer initialized [ 16.790811] Bluetooth: MGMT ver 1.22
firmware-nonfree - help needed ?
Hello there Ben! I hope Nattie and you had safe travels back from Kosovo! Having recently acquired a new laptop (X13 AMD gen2 from Lenovo); I tried the daily testing non-free d-i without being able to use the WiFi (finished the install over usb-to-android), which made me look at the needed firmwares, which made me realize that src:firmware-nonfree is somewhat outdated, which made me try to upgrade it [0] (which ended up permitting the use of a fresher binary for amdgpu). I was later also reminded that its outdated-ness created friction for some [1]. To make a long story short, it made me wonder if the Kernel Team wasn't in need of some help to maintain src:firmware-nonfree. Also, it will need moving to the new archive section, etc etc. Anyway, it seems I trapped myself in offering my modest help! What do you think? Best, OdyX [0] https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/23 [1] https://lists.debian.org/73fc8ae7-9bc1-00de-ed8e-fd8848198...@debian.org
Bug#948593: Unable to open LUKS device (error allocating crypto tfm) for aes / cbc-essiv:sha256 sha1 LUKS header
Package: src:linux Followup-For: Bug #948593 Of course, just after filing this bug, I remembered I could at least try with MODULES=most, which allowed me to boot. So the problem can be more accurately described as "some modules gone missing from 5.4+ kernel's initramfs'es with MODULES=dep for aes/cbc-essiv:sha256 LUKS header". >From the initramfs' modules' list; the diff (between 5.4.0-1 with MODULES=dep and 5.4.0-2 with MODULES=most) is attached. I don't really know if this is a src:linux problem, a src:initramfs-tools problem (although I'm also affected by #948257) or a missing configuration in my /etc/crypttab, but there's a regression somewhere! Cheers, and thanks for your help! OdyX -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH:fr (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/aegis128-aesni.ko usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/aesni-intel.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/blowfish-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/camellia-aesni-avx-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/camellia-aesni-avx2.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/camellia-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/cast5-avx-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/cast6-avx-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/chacha-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/crc32-pclmul.ko usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/crc32c-intel.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/crct10dif-pclmul.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/des3_ede-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/ghash-clmulni-intel.ko usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/glue_helper.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/poly1305-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/serpent-avx-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/serpent-avx2.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/serpent-sse2-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/sha1-ssse3.ko usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/sha256-ssse3.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/sha512-ssse3.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/twofish-avx-x86_64.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/twofish-x86_64-3way.ko +usr/lib/modules/LINUX-amd64/kernel/arch/x86/crypto/twofish-x86_64.ko usr/lib/modules/LINUX-amd64/kernel/crypto +usr/lib/modules/LINUX-amd64/kernel/crypto/aegis128.ko usr/lib/modules/LINUX-amd64/kernel/crypto/af_alg.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/algif_aead.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/algif_hash.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/algif_rng.ko usr/lib/modules/LINUX-amd64/kernel/crypto/algif_skcipher.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/ansi_cprng.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/anubis.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/arc4.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/asymmetric_keys +usr/lib/modules/LINUX-amd64/kernel/crypto/asymmetric_keys/pkcs8_key_parser.ko usr/lib/modules/LINUX-amd64/kernel/crypto/async_tx usr/lib/modules/LINUX-amd64/kernel/crypto/async_tx/async_memcpy.ko usr/lib/modules/LINUX-amd64/kernel/crypto/async_tx/async_pq.ko usr/lib/modules/LINUX-amd64/kernel/crypto/async_tx/async_raid6_recov.ko usr/lib/modules/LINUX-amd64/kernel/crypto/async_tx/async_tx.ko usr/lib/modules/LINUX-amd64/kernel/crypto/async_tx/async_xor.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/authenc.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/authencesn.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/blowfish_common.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/blowfish_generic.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/camellia_generic.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/cast5_generic.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/cast6_generic.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/cast_common.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/ccm.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/chacha20poly1305.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/chacha_generic.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/cmac.ko +usr/lib/modules/LINUX-amd64/kernel/crypto/crc32_ge
Bug#948593: Unable to open LUKS device (error allocating crypto tfm) for aes / cbc-essiv:sha256 sha1 LUKS header
Package: src:linux Version: 5.4.8-1 Severity: important Hello there, Since 5.4 kernels, my /dev/sda5 cannot be unlocked from initramfs anymore, so I can't boot under a 5.4* kernel (at least I haven't managed yet). Straight after typing my LUKS passphrase, I get "crypt: Error allocating crypto tfm". From diffing the initramfs'es, I see that kernel/arch/x86/crypto/aes-x86_64.ko was present in 5.3.0-3 kernels, but not present anymore in 5.4.0-1 or 5.4.0-2 kernels. # cryptsetup luksDump /dev/sda5 LUKS header information for /dev/sda5 Version:1 Cipher name:aes Cipher mode:cbc-essiv:sha256 Hash spec: sha1 Payload offset: 4096 MK bits:256 (…) -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 42914CG product_version: ThinkPad X220 chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: 8DET76WW (1.46 ) board_vendor: LENOVO board_name: 42914CG board_version: Not Available ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) Subsystem: Lenovo 2nd Generation Core Processor Family DRAM Controller [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics Controller [17aa:21da] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) Subsystem: Lenovo 6 Series/C200 Series Chipset Family MEI Controller [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) [8086:1502] (rev 04) Subsystem: Lenovo ThinkPad T520 [17aa:21ce] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: e1000e 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) (prog-if 20 [EHCI]) Subsystem: Lenovo 6 Series/C200 Series Chipset Family USB Enhanced Host Controller [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04) Subsystem: Lenovo 6 Series/C200 Series Chipset Family High Definition Audio Controller [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b4) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b4) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV-
Bug#843128: partially solved
Control: found -1 4.8.11-1 Le vendredi, 9 décembre 2016, 13.03:44 h CET Ben Hutchings a écrit : > fgetty uses dietlibc, and the stable version of dietlibc still uses the > vsyscall feature which is now disabled by default. You can make it > work again by adding 'vsyscall=emulate' to the kernel command line. > > I'll have to reconsider whether to revert the configuration change now > that I know dietlibc is a problem. On a vagrant-lxc setup using Liip's drifter [0], we see two different programs segfaulting immediately after a vsyscall entry in syslog: Dec 19 10:07:55 gyllingar kernel: [ 834.998381] logsave[12259] vsyscall attempted with vsyscall=none ip:ff600400 cs:33 sp:7ffc918c1fc8 ax:ff600400 si:4017c1 di:0 Dec 19 10:07:55 gyllingar kernel: [ 834.998384] logsave[12259]: segfault at ff600400 ip ff600400 sp 7ffc918c1fc8 error 15 Dec 19 10:07:55 gyllingar kernel: [ 834.998934] ip[12261] vsyscall attempted with vsyscall=none ip:ff600400 cs:33 sp:7fff467d8d18 ax:ff600400 si:433d2f di:0 Dec 19 10:07:55 gyllingar kernel: [ 834.998936] ip[12261]: segfault at ff600400 ip ff600400 sp 7fff467d8d18 error 15 So apparently /sbin/logsave from src:e2fsprogs and /sbin/ip from src:iproute2 have the same problem. And this was on linux-image-4.8.0-2-amd64 4.8.11-1. Both problems are circumvented by booting with vsyscall=emulated on the kernel command line. Cheers, OdyX [0] https://github.com/liip/drifter signature.asc Description: This is a digitally signed message part.
Re: Bug#779919: usb-modeswitch: IOMMU in BIOS not handled properly
reassign -1 linux 3.16.7-ckt4-3 Le vendredi, 6 mars 2015, 07.35:44 William Melgaard a écrit : > Dear Maintainer, > >* What led up to the situation? > The default IOMMU setting in the BIOS for a GIGABYTE motherboard is > off. Attempting to install a Debian system (Wheezy or Jessie AMD-64) > with this setting results in not recognizing USB mouse or keyboard. > However, booting with Squeeze or Wheezy 386 does work with this > setting. >* What exactly did you do (or not do) that was effective (or > ineffective)? > Turned on the IOMMU support >* What was the outcome of this action? > Although the USB-2 mouse and keyboard are dealt with effectively with > IOMMU enabled, there are ~550 lines of "page fault" reported by dmesg > at bootup. Further investigaiton finds that failure to access the > northbridge (AMD 970 chip) USB-3 support is the cause of the page > faults. >* What outcome did you expect instead? > Everything to work This has most likely nothing to do with usb-modeswitch, which doesn't handle the USB devices itself, but only ever through the Linux kernel. Hereby reassigning. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1522073.0iGVUiLYL7@gyllingar
Re: Building d-i using wheezy-backports bits
Hi Cyril, Le jeudi, 30 janvier 2014, 02.51:48 Cyril Brulebois a écrit : > as mentioned earlier this month, I had a little proof of concept for > Paris Mini-DebConf 2014[1]. I've polished a few things, so here we go. > > 1. https://lists.debian.org/debian-boot/2014/01/msg00239.html Thanks for the report; your progress on that front is really awesome! > I. How to build and run images > == > > At least 2 source packages need updating: > > 1. debian-installer, so that one can upload to wheezy-backports, and > get extra bits set up, in order to pull the kernel and some kernel > modules from wheezy-backports. You can find a few patches for this in > my wheezy-backports-v3 branch: > (… > QUESTION: How to specify which extra bits to pull from > wheezy-backports? The most logical place to store this information would be in build/pkg- lists/, with either version specifiers ( lowmemcheck=1.40~bpo70+1 ) or target release specifiers ( lowmemcheck/wheezy-backports ). That's for storing the information; but that involves patching various tools. The first I've encountered was get-packages (patch attached). As far as I could test, the attached patch is sufficient to allow either of the syntaxes in build/pkg-lists/ to build netboot-gtk on amd64. (Now that's probably unrelated, but mini.iso fails on me with "Kernel panic - not syncing: No init found.") > 2. net-retriever, which needs to pull regular bits from wheezy, and > kernel module udebs from wheezy-backports. Unfortunately, contrary > to the above, anna is used here, instead of apt. That means using an > overlay (not self-contained) suite like wheezy-backports isn't > possible by default. > (…) > I'm not yet convinced about “resolve conflicts with backports” > vs. “resolve conflicts with stable”. > (…) > QUESTION: Should we pick a different policy? If we were to pick a > handful of packages from backports, how to do that? > [Also, see above question.] (Easier said than done, but) I would tend to think that making anna understand both of the above syntaxes would empower it most. Now, that's certainly quite a bunch of work and I think your approach of merging the Packages* files is good for now. As for conflicts resolution, I agree with your current "resolve conflicts with backports", given that most udebs are uploaded by -boot (meaning that udebs in backports are there for a reason). The next step (as you wrote) would be to allow suite or version specifications to be consumed by the Packages* files merger, which is still quite easier than patching anna's resolver I guess. > II. How to install a backported kernel > == > (…) > Now here's another way which doesn't look so scary: > > 1) Make sure the kernel installation step still installs stable's > kernel (which might not be functional, but having it shouldn't > hurt; and not changing such critical code doesn't look too > bad…), and make sure it stores the package name somewhere for > later use. Sure. Having the stable kernel installed in all cases is definitely good. > 2) Patch apt-setup so that wheezy-backports gets automatically > enabled when such an installation medium is detected >(e.g. /etc/udeb-backports-source exists). That would be patching /usr/lib/apt-setup/generators/93backports to ignore apt-setup/services if the flagfile exists; patch attached. > QUESTION: Is there any saner/more straightforward/better option here? > > QUESTION: How do we make sure we pull the relevant patched packages at > this point? (apt-setup comes to mind, ditto for the package possibly > containing the finish-install script.) Hrm. base-installer/library.sh 's pick_kernel makes sure that one gets the "currently running" kernel image installed. It might be easier to let that happen and _then_ make sure stable's kernel is installed… Note that it uses `apt-cache search "^linux-image"` in the target to find the needed packages… I'm not navigating very easily through these installation steps, so I'll let someone else chime with better ideas here… > IV. How to maintain wheezy-backports compared to master > === > > Since master both gets kernel config updates (which we want for > backports) and many other irrelevant stuff, I'm a bit undecided on how > to keep track of wheezy-backports: either cherry-pick relevant stuff > from master; or merge regularly, reverting unnecessary bits. I would > tend to go with the former. It looks like a matter of intent: either we want "stable d-i + kernel from backports + glue" or "testing d-i built against stable + kernel from backports". The first is less risky for what d-i is concerned, while the latter allows a wider testing of the jessie d-i… The latter is what you have in your branch currently, no? As for maintaining the branches, I'd rather go for
Bug#691427: journal commit I/O error on brand-new Thinkpad T430s ext4 on lvm on SSD
Hi Jonathan, Le jeudi, 25 octobre 2012 22.25:03, Jonathan Nieder a écrit : > Didier Raboud wrote: > > Tags: upstream > > What upstream version did you test? Well we only tried packaged kernels, all wheezy, unstable and experimental exhibit this behaviour. We started to compile an upstream kernel but didn't try yet. I tagged this bug as "upstream", considering it's probably not a bug of the packaging. > Can you get full "dmesg" output when in this state? A serial console[1] or > netconsole[2] might be helpful in obtaining that, or if that's not > possible, a photograph of messages on the screen will do in a pinch. I'll let Dorian send that to the bug, we'll see what that gives. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210261344.35883.o...@debian.org
Bug#613662: unmet dependencies race condition
Le Thursday 17 February 2011 11:30:40 jida...@jidanni.org, vous avez écrit : > Why can't they simply ensure the lower layers in this particular > dependency pyramid are sent out before or at the same time as the other > parts? Because it's not important in unstable (as it gets solved over time)! You are using unstable, that is a suite _designed_ to suffer those issues _all_the_time_ (and will continue to do so). If you want a system that doesn't have this type of problems; use testing! > Anyway, there upon full upgrade we get asked: > (…) > One slip of the finger and we have removed our operating system, "never > to boot again", "it was time for grandpa to retire anyway". > > Yes of course it will probably ask us "are we sure?". … This happens because you try a "full upgrade", which is the _WRONG_ thing to do when using unstable. I mentioned you already that using "safe-upgrade" or "upgrade" doesn't trigger that type of problems. So you should really try using the correct tools for the suite you are using; expectations you can have on stable are not the same than the ones you can have on unstable; both imply different use cases, different tools and different temporary issues. Now there is plenty of documentation out there that will explain this better than me; please let this non-bugreport die. -- Didier Raboud, proud Debian Developer. CH-1020 Renens o...@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102171144.55600.o...@debian.org
Bug#613662: unmet dependencies race condition
Le Thursday 17 February 2011 02:04:27 jida...@jidanni.org, vous avez écrit : > >>>>> "D'R" == Didier 'OdyX' Raboud writes: > D'R> Such temporary glitches are perfectly normal (and transitional) in the > unstable D'R> distribution. All those packages are built and uploaded, > they will reach your D'R> mirror really soon now. Hence closing this > non-bug. > > Can't they be sent in a different order so as not to expose the problem? This is not feasible, because of the nature of unstable. Packages get uploaded and get auto-built by build daemons after the upload. As building packages can take much time, it is frequent to have architectures that have many more packages built than others. On those 'slow' architectures, unsatisfied dependencies are frequent, but almost always get solved by _waiting_ (I run 'aptitude update; aptitude safe-upgrade' daily and I don't even see these issues). Hence you cannot expect developers to wait for _all_ architectures to be up2date to upload packages that depend on a given package, that would just slow up things for no benefit. If you want a system that has no such things, you should try testing (currently Wheezy) or even stable (currently Squeeze), whose migration scripts are _designed_ to avoid this. Unsatisfied dependencies in the testing or sable suites are bugs; in unstable they are not (and cannot be, for the reasons explained above). Regards, OdyX -- Didier Raboud, proud Debian Developer. CH-1020 Renens o...@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102171102.38113.o...@debian.org
Bug#607669: linux-image-2.6.37-rc5-amd64: Dell Latitude D630 backlight fails to resume to "on"
reopen 607669 found 607669 2.6.37-1~experimental.1 retitle 607669 linux-image-2.6.37-trunk: Dell Latitude D630 backlight fails to resume to "on" thanks Hi, sorry, but despite what I thought, this has happened again using the 2.6.37- trunk version. Hence re-opening. Cheers, OdyX -- Didier Raboud, proud Debian Developer. CH-1020 Renens o...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#602444: firmware-brcm80211: Kernel Panic on "iwlist scan"
tags 602444 -patch thanks Hi Ben, and thanks for your answer, Le jeudi 4 novembre 2010 23:37:48 Ben Hutchings, vous avez écrit : > On Thu, 2010-11-04 at 22:52 +0100, Didier Raboud wrote: > > Package: firmware-brcm80211 > > What has this got to do with the firmware? The observable facts I could get is that: * the boot completes when the package is not installed * the boot stop with a Kernel Panic (or an Oops, I could not see exactly) when the package is installed. I don't know the details of how it works internally, so I directed my suspicion against the firmware-* package. Thanks to you and Julien for the re-assigning. > > Justification: breaks the whole system > > No it doesn't. I don't intend to play severity ping-pong, but "Impossible to boot, Kernel Panic at each boot" doesn't sound below RC to me. > > I tested that here and it works. > > [...] > > That's odd because this module doesn't have such an option. 'maxcpus=1' > is a kernel command-line parameter, and strangely enough we do not want > to use it. Yeah, I completely overlooked that; sorry. My approach was plain wrong. Now I conducted a more precise investigation, _with_ the firmware-brcm80211 package installed. I booted in "single" mode, hence getting a root console. No problem so far; the module is loaded. Running "iwlist scan" from that "single" root console leads to 100% reproducible oops. So my guess is that Network-Manager uses the driver, eventually triggering a scan and then kernel oopses at that moment, leading to a non-completed boot. Would you need more information ? Of what sort ? For now, I uninstalled the firmware package and will try with the broadcom-sta stack, unfortunately from non-free. Cheers, OdyX -- Didier Raboud, proud Debian Maintainer (DM). CH-1020 Renens did...@raboud.com signature.asc Description: This is a digitally signed message part.
Bug#602444: Too fast !?
Hrm, I was probably shooting too fast: it didn't work - I believed it did as by "not" loading the module, it allowed to boot without panic, but no wireless. More tomorrow, cheers, OdyX -- Didier Raboud, proud Debian Maintainer (DM). CH-1020 Renens did...@raboud.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201011042318.30558.did...@raboud.com
Bug#595661: bug 595661 is forwarded to alsa-de...@alsa-project.org
Le dimanche 5 septembre 2010 17:56:44 Ben Hutchings, vous avez écrit : > forwarded 595661 alsa-de...@alsa-project.org > thanks Hi Ben, where has that bug been forwarded ? I can't find a trace of it in the alsa- de...@a-p.org during September. Cheers, OdyX -- Didier Raboud, proud Debian Maintainer (DM). CH-1020 Renens did...@raboud.com signature.asc Description: This is a digitally signed message part.
Bug#595661: Acknowledgement (linux-image-2.6.35-trunk-amd64: [Alsa] Initial offset in volume adjustment sliders (sound stops before 0))
reassign 595661 src:linux-2.6 2.6.35-1~experimental.2 found 595661 2.6.32-21 thanks Hi, I just tested with Sid/Squeeze's kernel: I can reproduce the behaviour, hence marking "found" correctly (and marking as found on source as the binary packages names differ; please correct to match your workflow [and sorry if I mis-did]). By the way, I found an empirical thing: sounds is outputted through the headphones when the "master" and "Headphone" levels sum strictly bigger than 100. Aka: if master + Headphone <= 100; sound_headphone <= '0'; endif; :p Cheers, OdyX -- Didier Raboud, proud Debian Maintainer (DM). CH-1020 Renens did...@raboud.com signature.asc Description: This is a digitally signed message part.
Bug#568126: lm-sensors: Resource conflicts policy in kernel has changed
Le lundi 2 août 2010 00:27:10, vous avez écrit :
> On Fri, Feb 05, 2010 at 11:58:36AM -0500, Dave Witbrodt wrote:
> > Package: lm-sensors
> > Severity: normal
> >
> >
> > This looks like a consequence of a recent change in kernel policy
> > regarding resource conflicts. According to the 'kernel-parameters.txt'
> > file in the kernel documentation, the default value of the parameter
> > "acpi_enforce_resources" has changed:
> >
> > $ grep -A 15 acpi_enforce_resources Documentation/kernel-parameters.txt
> >
> > acpi_enforce_resources= [ACPI]
> >
> > { strict | lax | no }
> > Check for resource conflicts between native drivers
> > and ACPI OperationRegions (SystemIO and SystemMemory
> > only). IO ports and memory declared in ACPI might be
> > used by the ACPI subsystem in arbitrary AML code and
> > can interfere with legacy drivers.
> > strict (default): access to resources claimed by ACPI
> > is denied; legacy drivers trying to access reserved
> > resources will fail to bind to device using them.
> > lax: access to resources claimed by ACPI is allowed;
> > legacy drivers trying to access reserved resources
> > will bind successfully but a warning message is logged.
> > no: ACPI OperationRegions are not marked as reserved,
> > no further checks are performed.
> >
> > I recently resolved a very similar issue myself by adding
> > "acpi_enforce_resources=lax" to my kernel boot line in GRUB.
>
> Didier, does this fix the issue for you?
>
> Cheers,
> Moritz
Hi Moritz,
yes it does. But if this option is to stay, it really should get either i) set
automagically by ii) documented visibly in
release notes maybe ?
Thanks for your following-up on that bug.
Cheers, OdyX
--
Didier Raboud, proud Debian Maintainer (DM).
CH-1020 Renens
did...@raboud.com
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201008051730.09081.did...@raboud.com
