Re: No longer sign i386 kernels

[Pascal Hambourg]

Hello,

On 06/12/2023 at 22:09, Steve McIntyre wrote:


On Wed, Dec 06, 2023 at 06:01:17PM +0100, Bastian Blank wrote:


I would like do stop signing i386 kernels.

- IA32 UEFI is basically non existent outside of the Apple world and
  maybe some embedded stuff.

(...)

there's no point in signing i386 grub and fwupd or
having a signed shim if we don't have a signed kernel.


Over the years I have seen a number of netbook or tablet-style PCs with 
32-bit UEFI firmware and a 64-bit capable CPU, so they could boot with 
grub-efi-ia32 and an amd64 kernel. I do not remember if they supported 
secure boot though.

Bug#1032271: Module advansys fails to load on amd64

[Pascal Hambourg]

Package: src:linux
Version: 5.10.162-1
Severity: normal

Dear maintainer,

Loading the 'advansys' module fails with any -amd64 kernel:

# modprobe advansys
modprobe: ERROR: could not insert 'advansys': No such device

The module loads successfully with any -686 or -686-pae kernel.

I observed the same behaviour with any stable Debian kernel from 4.9 to 
6.1 I have, regardless of whether the supported device and required 
firmware are present or not.


After adding a few printk() in the module code, it appears that the 
reason is because calls to isa_register_driver() in advansys_init() 
fail. The failure may be related with some ISA-related config option 
missing in amd64 kernels. A quick comparison shows that the following 
options are enabled in -686 config but not in -amd64 config:


CONFIG_ISA=y
CONFIG_ISA_BUS_API=y
CONFIG_ISAPNP=y

However I believe a better solution would be to have the module not fail 
if ISA is disabled, as it also support EISA and PCI devices.

Bug#980450: Bug 980450: Module ohci-hcd does not detect USB 1.1 devices

[Pascal Hambourg]

Control: found 980450 4.19.160-2

Hello folks,

Having read the original thread in french and helped another user with 
the same issue, I would like to add some clarifications.


The bug submitter has the following hardware :

00:03.0 USB controller [0c03]: Silicon Integrated Systems [SiS] USB 1.1 
Controller [1039:7001] (rev 0f) (prog-if 10 [OHCI])

  Subsystem: ASUSTeK Computer Inc. USB 1.1 Controller [1043:1977]
  Kernel driver in use: ohci-pci

The issue could not be reproduced with Nvidia USB 1.1 OHCI controllers.

The bug submitter found two different workarounds :
1) unloading and reloading the ohci-pci module
2) loading the ohci-hcd module with distrust_firmware=0


Here is another thread (also in french) discussing the issue :


with the following hardware :

00:1c.0 USB controller [0c03]: ULi Electronics Inc. USB 1.1 Controller 
[10b9:5237] (rev 03)

  Subsystem: Acer Incorporated [ALI] USB 1.1 Controller [1025:0085]
  Kernel driver in use: ohci-pci

The issue is the same: when booting with linux-image-4.19.0-13-amd64 
(4.19.160-2), USB 1.1 devices are not detected in the kernel logs. When 
booting with previous kernels, USB 1.1 devices are detected as expected. 
USB 2.0 devices do not seem to be affected. Workaround #2 worked. 
Workaround #1 was not tried.



The issue is likely to be caused by the following change backported from 
kernel 5.10:


 usb: ohci: Default to per-port over-current protection

Interestingly, another patch from the same author was included into 
kernel 5.10 at the same time but not backported in longterm series 4.9 
and 4.19, and does the same as workaround #2 :


 usb: ohci: Make distrust_firmware param default to false

Bug#638656: closed by Ben Hutchings b...@decadent.org.uk (Bug#638656: fixed in linux-2.6 2.6.32-36)

[Pascal Hambourg]

Hello,

Debian Bug Tracking System a écrit :
* Add longterm release 2.6.32.44, including:
[...]
  - atm: [br2684] allow routed mode operation again

Note that this also fixes bug #636781.



--
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/4e705a85.2060...@plouf.fr.eu.org

Bug#636781: acknowledged by developer (closing 638656)

[Pascal Hambourg]

Why were bugs #636781 and #638656 merged ? They are completely different
bugs. Bug #636781 affects only the version 2.6.32-35 of linux-2.6 while
bug #638656 also affects several other versions.

Shouldn't bug #636781 have been merged with bug #639425 (Changes from
longterm 2.6.32.44) instead ?



-- 
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/4e70c4df.2090...@plouf.fr.eu.org

Bug#638656: br2684: Sent packets truncated in VC routed mode

[Pascal Hambourg]

Package: linux-2.6
Version: 3.0.0-2
Tags: upstream, patch, fixed-upstream

Hello,

The transmit function for VC-MUX routed encapsulation wrongly
strips an ethernet header from IP packets, but there is no ethernet
header so it actually truncates the IP header.

The bug was introduced in Linux 2.6.26. It was fixed upstream in
Linux 3.1-rc1 and 3.0.3 by the following patch which has been added to
the 2.6.32-longterm queue and will hopefully be included in the next
2.6.32.46 release.

Please fix Linux 2.6.32 in Squeeze/stable.

The bug also exists in Linux 2.6.26 in Lenny/oldstable but the br2684ctl
package in Lenny/oldstable does not support routed mode.

Regards.

---

commit 55041e081ef433774279ecb6fc3fd30f741f5f37
From: Chas Williams c...@cmf.nrl.navy.mil
Date: Mon, 1 Aug 2011 17:56:14 -0700
Subject: atm: br2864: sent packets truncated in VC routed mode

commit a08af810cdc29d2ca930e8a869d3d01744c392d8 upstream.

Reported-by: Pascal Hambourg pas...@plouf.fr.eu.org
Signed-off-by: Chas Williams c...@cmf.nrl.navy.mil
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 net/atm/br2684.c |2 --
 1 file changed, 2 deletions(-)

--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -242,8 +242,6 @@ static int br2684_xmit_vcc(struct sk_buf
if (brdev-payload == p_bridged) {
skb_push(skb, 2);
memset(skb-data, 0, 2);
-   } else { /* p_routed */
-   skb_pull(skb, ETH_HLEN);
}
}
skb_debug(skb);




-- 
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/4e4fdfbd.3040...@plouf.fr.eu.org

Bug#636781: br2684: Routed mode interface cannot be activated

[Pascal Hambourg]

Pascal Hambourg wrote :
 
 The bug was fixed upstream in kernel 2.6.33 by the following patch, which
 has not been backported in upstream 2.6.32-stable yet (I have submitted a
 request to include it).

The patch has been included in the new kernel 2.6.32.44 upstream.
commit 58e6859b0205a2394387a1e16a5bf455f24d4611



-- 
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/4e406562.60...@plouf.fr.eu.org

Bug#636781: br2684: Routed mode interface cannot be activated

[Pascal Hambourg]

Package: linux-2.6
Version: 2.6.32-35
Tags: patch, fixed-upstream

Hello,

Due to a regression introduced in kernel 2.6.30, attempts to activate a
nasX interface created by br2684ctl in routed mode may fail because of
improper hardware address validation (a routed point-to-point interface
obviously has no hardware address). Activation works for a virtual ATM interface
created by atmtcp from atm-tools, but fails for the real ATM interface created
by my ADSL USB modem.

A workaround is to set a hardware address before activating the interface.

The bug was fixed upstream in kernel 2.6.33 by the following patch, which
has not been backported in upstream 2.6.32-stable yet (I have submitted a
request to include it).

Regards.

---

commit 2e302ebfeac04beb5a5d6af1ac583c6a1fb76d1a upstream
Author: chas williams - CONTRACTOR c...@cmf.nrl.navy.mil
Date: Fri, 4 Dec 2009 11:06:32 +

atm: [br2684] allow routed mode operation again

in routed mode, we don't have a hardware address so netdev_ops doesnt
need to validate our hardware address via .ndo_validate_addr

Reported-by: Manuel Fuentes mfuen...@agenciaefe.com
Signed-off-by: Chas Williams - CONTRACTOR c...@cmf.nrl.navy.mil
Signed-off-by: David S. Miller da...@davemloft.net
---
 net/atm/br2684.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 26a646d..c9230c3 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -554,6 +554,12 @@ static const struct net_device_ops br2684_netdev_ops = {
.ndo_validate_addr  = eth_validate_addr,
 };

+static const struct net_device_ops br2684_netdev_ops_routed = {
+   .ndo_start_xmit = br2684_start_xmit,
+   .ndo_set_mac_address= br2684_mac_addr,
+   .ndo_change_mtu = eth_change_mtu
+};
+
 static void br2684_setup(struct net_device *netdev)
 {
struct br2684_dev *brdev = BRPRIV(netdev);
@@ -569,11 +575,10 @@ static void br2684_setup(struct net_device *netdev)
 static void br2684_setup_routed(struct net_device *netdev)
 {
struct br2684_dev *brdev = BRPRIV(netdev);
-   brdev-net_dev = netdev;

+   brdev-net_dev = netdev;
netdev-hard_header_len = 0;
-
-   netdev-netdev_ops = br2684_netdev_ops;
+   netdev-netdev_ops = br2684_netdev_ops_routed;
netdev-addr_len = 0;
netdev-mtu = 1500;
netdev-type = ARPHRD_PPP;



-- 
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/4e3c62b9.2070...@plouf.fr.eu.org

Bug#541169: linux-image-2.6.30-1-amd64 : sis190 driver doesn't work with Ethernet Adpator

[Pascal Hambourg]

Hello,

Moritz Muehlenhoff a écrit :
 On Wed, Aug 12, 2009 at 06:27:19AM +0200, Pierre Meurisse wrote:

 My Ethernet device is unusable with amd64 kernels (2.6.26 ... 2.6.30).
 When connected to a dhcp server, the system gets a IP address, but
 no connection is possible 
 
 You might have been bitten by 
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=744c6b2976778ac6944e580fc413842df85be84e
  ?

FYI : Setting the module parameter 'rx_copybreak' to a low value (below
the smallest packet size expected to be received, I suggested 14 but
there may be a more adequate value) may be used as a workaround. However
I don't know if it may have adverse effets.



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org