Bug#1062235: wireless-regdb: debci test fails with OpenSSL 3.2.
Package: wireless-regdb Version: 2022.06.06-1 Severity: important Tags: sid control: affects -1 src:openssl User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-3.2 OpenSSL 3.2 adds output on stderr if no input file as been specified and input from stdin is expected. This additional output on stderr causes the debci test to fail. Please add either "Restrictions: allow-stderr" to debian/tests/control in order to allow output on stderr or add "-in /dev/stdin" as an argument to the "openssl x509" invocation (convert_cert_der_to_pem). Sebastian
Bug#1002537: linux-image-5.15.0-2-rt-amd64: RT kernel does not support touchpad/trackpoint on Thinkpad L15
control: tags -1 - moreinfo control: fixed -1 5.17~rc6-1~exp1 On 2022-01-16 17:04:57 [+0100], Salvatore Bonaccorso wrote: > Hi Michael, Hi Salvatore, > Where you by chance already able to test this? Just some updates: - The issue is going to be addressed by https://lore.kernel.org/all/20220211181500.1856198-1-bige...@linutronix.de - The series will hit v5.18 - The series is part of v5.17-rc5-rt9, was backported to v5.15.25-rt33 and will also make into to the other maintained trees. I guess this closes the case. I did internationally not close the bug. > Regards, > Salvatore Sebastian
Bug#1005400: firmware-nonfree: Please package AMD SEV firmware.
Package: firmware-nonfree Version: 20210818-1 Severity: normal Hi, The orig contains already the AMD SEV firmware in the amd folder: | $ ls -lh amd | 33K Aug 18 13:08 amd_sev_fam17h_model0xh.sbin | 43K Aug 18 13:08 amd_sev_fam17h_model3xh.sbin Could this be please package? I have an AMD box asking for this. Sebastian
Bug#1002537: linux-image-5.15.0-2-rt-amd64: RT kernel does not support touchpad/trackpoint on Thinkpad L15
On 2021-12-25 12:27:33 [+0100], Michael Below wrote: > Hi, Hi, > I have tested the patch, with help from Salvatore, and the dmesg output > looks better, but the touchpad still does not work. I am attaching the > dmesg output. based on > [1.575843] idma64 idma64.0: Found Intel integrated DMA 64-bit > [1.578321] i801_smbus :00:1f.4: SPD Write Disable is set > [1.578365] genirq: Flags mismatch irq 16. 00010080 (i801_smbus) vs. > 2080 (idma64.0) > [1.578368] i801_smbus :00:1f.4: Failed to allocate irq 16: -16 > [1.578370] i801_smbus :00:1f.4: SMBus using polling the IRQ can not be non-threaded because it is shared with idma64. Good. Based on output it says that it is using polling so I'm don't know why the touchpad is not working… What about the following hunk instead? diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 73253e667de1d..30e93651d5b6b 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -1423,7 +1423,10 @@ int i2c_handle_smbus_host_notify(struct i2c_adapter *adap, unsigned short addr) if (irq <= 0) return -ENXIO; - generic_handle_irq(irq); + if (!IS_ENABLED(CONFIG_PREEMPT_RT)) + generic_handle_irq(irq); + else + handle_nested_irq(irq); return 0; } > Cheers > Michael Sebastian
Bug#1002537: linux-image-5.15.0-2-rt-amd64: RT kernel does not support touchpad/trackpoint on Thinkpad L15
control: tags -1 patch
On 2021-12-23 21:30:28 [+0100], Michael Below wrote:
> [ 20.096966] CPU: 2 PID: 223 Comm: irq/16-i801_smb Not tainted
> 5.15.0-2-rt-amd64 #1 Debian 5.15.5-1
The hunk at the bottom should cure it.
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 1f929e6c30bea..6723af1057b69 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1849,7 +1849,7 @@ static int i801_probe(struct pci_dev *dev, const struct
pci_device_id *id)
init_completion(>done);
err = devm_request_irq(>dev, dev->irq, i801_isr,
- IRQF_SHARED, DRV_NAME, priv);
+ IRQF_SHARED | IRQF_NO_THREAD, DRV_NAME,
priv);
if (err) {
dev_err(>dev, "Failed to allocate irq %d: %d\n",
dev->irq, err);
Sebastian
Bug#996419: gcc-11: Fails to compile the linux kernel on ARM.
Package: gcc-11 Version: 11.2.0-9 Severity: important The linux kernel has the following in its ARM Makefile: $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a) This means the switch "-march=armv7-a" is tested if supported by the compiler and if so it is used, otherwise it uses the alternative "-march=armv5t -Wa,-march=armv7-a". On gcc-10 it evaluated to "-march=armv7-a". On gcc-11 it evaluates to "-march=armv5t -Wa,-march=armv7-a" leading to compile errors: | cccHPwDp.s:4372: Error: selected processor does not support `cpsid i' in ARM mode | cccHPwDp.s:5145: Error: selected processor does not support `cpsid i' in ARM mode | cccHPwDp.s:5393: Error: selected processor does not support `cpsie i' in ARM mode | cccHPwDp.s:5530: Error: selected processor does not support `dsb ' in ARM mode | cccHPwDp.s:6088: Error: selected processor does not support `cpsie i' in ARM mode | cccHPwDp.s:7132: Error: architectural extension `mp' is not allowed for the current base architecture | cccHPwDp.s:7133: Error: selected processor does not support `pldw [r4]' in ARM mode | cccHPwDp.s:7136: Error: selected processor does not support `pld [r4]' in ARM mode | cccHPwDp.s:7148: Error: selected processor does not support `ldrex r3,[r4]' in ARM mode | cccHPwDp.s:7150: Error: selected processor does not support `strex r1,r2,[r4]' in ARM mode This has been noticed in the gcc-11-arm-linux-gnueabihf package and verified on a armhf porter box with the native gcc-11 package. The test fails due to: | $ arm-linux-gnueabihf-gcc-10 -o a.o a.c -march=armv7-a | $ arm-linux-gnueabihf-gcc-11 -o a.o a.c -march=armv7-a | cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU Passing early -msoft-float to the compiler test solves the problem. This option is passed later to the compile process. Is this change intended? Sebastian
Broadcom bluetooth firmware
Hi, I have USB BT stick from Broadcom. lsusb says: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0 and once the driver is loaded it needs firmware: | Bluetooth: hci0: BCM20702A1 (001.002.014) build 1764 | bluetooth hci0: firmware: direct-loading firmware brcm/BCM20702A1-0a5c-21e8.hcd I couldn't find the firmware in any Debian package. I found the firmware at https://github.com/winterheart/broadcom-bt-firmware which does not look like the official repository. Is this something we can ship or is there another way which I missed completely? Sebastian
Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201
On 2018-12-15 22:21:52 [+0100], Cyril Brulebois wrote: > regular bugfixes; we seem to have missed this regression on gen4/gen5, > so I've started checking whether the upstream fix was being queued for > linux-4.18.y, and moved to trying to get a work around once I've noticed that bug is a bummer. I reverted that one patch myself for my needs. v4.18 isn't maintained anymore so I'm unsure if this gets fixed in the stable tree. Debian wise I *think* they will move to v4.19 soon. > Cheers, Sebastian
Bug#846597: linux: please enable `perf data' support
On 2017-01-26 16:36:45 [+0100], Hector Oron wrote: > Hello, Hi, > On Fri, Dec 02, 2016 at 02:37:21PM +0100, Sebastian Andrzej Siewior wrote: > > diff --git a/debian/templates/control.source.in > > b/debian/templates/control.source.in > > index 08969a3da9d9..2a1fdf048823 100644 > > --- a/debian/templates/control.source.in > > +++ b/debian/templates/control.source.in > > @@ -41,6 +41,8 @@ Standards-Version: 3.9.8 > > libperl-dev , > > libunwind8-dev [amd64 armel armhf arm64 i386] > !nopython>, > > python-dev , > > + libbabeltrace-dev , > > + libbabeltrace-ctf-dev , > > Out of curiosity, > > The final patch that got merged has versioned depends on babeltrace >=1.5.0, > but > Jessie has 1.2.3. While trying to do a linux kernel backport, I have come up > with a question if we really need babeltrace >=1.5.0 or if 1.2.3 has the > needed > features. Do you happen to know? You need babeltrace >= 1.5.0 for perf-data to work and that was the whole point of libbabeltrace. If you don't care about perf-data you can drop that babeltrace dependency (and not enable it later while building perf). I am happy that the next stable will bring working perf-data to Debian and I don't need it in backports (as it will introduce yet another library). > Note: In anycase, I am preparing a backport of babeltrace. > > Regards Sebastian
Re: installing kernel debug symbols on stretch?
On 2017-01-14 11:06:51 [+0100], Daniel Pocock wrote: … > deb http://debug.mirrors.debian.org/debian-debug/ stretch-debug main > non-free contrib not that this changes anything, but I assumed that deb http://deb.debian.org/debian-debug stretch-debug main was the way to use for stretch+. But this does not change a thing… > # apt-get install -t stretch-debug linux-image-amd64-dbgsym … > The following packages have unmet dependencies: > linux-image-amd64-dbgsym : Depends: linux-image-4.8.0-2-amd64-dbgsym > but it is not installable > E: Unable to correct problems, you have held broken packages. … > so would the dbgsym package still be in Incoming? No, it is still there: http://deb.debian.org/debian-debug/pool/main/l/linux/linux-image-4.8.0-2-amd64-dbgsym_4.8.15-2_amd64.deb it is just not listed in the Packages file where it should be. I *think* the archive got confused by the various kernel package. So we have linux-image-4.8.0-2-amd64-dbgsym which comes out of src:linux and binary:linux-image-4.8.0-2-amd64-unsigned. Then we have the binary package linux-image-4.8.0-2-amd64 which comes out of src:linux-signed and has no dbgsym package but the one provided by linux-image-4.8.0-2-amd64-unsigned is just fine. I would assume that if nothing changes, we will miss the dbgsym package in testing for 4.9 in approx 8 days. There is not such a problem for mips64el where we don't have linux-signed and so linux-image-4.8.0-2-octeon-dbgsym is listed in testing. Could someone from ftp please confirm this? > Regards, > > Daniel Sebastian
Bug#846597: linux: please enable `perf data' support
Package: src:linux Version: 4.9~rc5-1~exp1 Severity: normal Tags: patch Please enable `perf data' support for perf. This requires two extra dependencies which are already in debian in the required version. During the invocation of make (for perf) you libbabeltrace needs to be explicitly enabled. Upstream disabled it by default until more distros ship a libbabeltrace with the requested functions (and Debian is the first one). All this can be found in the patch attached. Sebastian From: Sebastian Andrzej Siewior <sebast...@breakpoint.cc> Date: Fri, 2 Dec 2016 13:09:45 + Subject: [PATCH] perf: enable perf data support Signed-off-by: Sebastian Andrzej Siewior <sebast...@breakpoint.cc> --- debian/rules.d/tools/perf/Makefile | 3 +++ debian/templates/control.source.in | 2 ++ 2 files changed, 5 insertions(+) diff --git a/debian/rules.d/tools/perf/Makefile b/debian/rules.d/tools/perf/Makefile index aa50e42efc3a..ec0c9e97486d 100644 --- a/debian/rules.d/tools/perf/Makefile +++ b/debian/rules.d/tools/perf/Makefile @@ -48,6 +48,9 @@ MAKE_PERF += feature-libbfd=0 HAVE_CPLUS_DEMANGLE_SUPPORT=1 # an explicit exception. Override detection of libcrypto. MAKE_PERF += NO_LIBCRYPTO=1 +# Currently babeltrace support for `perf data' is not automatically detected. +MAKE_PERF += LIBBABELTRACE=1 + all: ifdef KERNEL_ARCH_PERF # perf changes some default directories depending on whether DESTDIR is diff --git a/debian/templates/control.source.in b/debian/templates/control.source.in index 08969a3da9d9..2a1fdf048823 100644 --- a/debian/templates/control.source.in +++ b/debian/templates/control.source.in @@ -41,6 +41,8 @@ Standards-Version: 3.9.8 libperl-dev , libunwind8-dev [amd64 armel armhf arm64 i386] , python-dev , + libbabeltrace-dev , + libbabeltrace-ctf-dev , # used by upstream to build usbip autoconf , automake , -- 2.10.2
Bug#759656: [PATCH] mmc: card: not access RPMB partition for normal read and write
On 05/06/2015 03:06 PM, Ulf Hansson wrote: On 12 August 2014 at 06:01, Yunpeng Gao yunpeng@intel.com wrote: From: Chuanxiao Dong chuanxiao.d...@intel.com Sorry for the delay and thanks! ah thanks. Is it likely you go via my patches for mmc-utils in the new few days? Kind regards Uffe Sebastian -- 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/554a12a0.6030...@linutronix.de
Bug#780107: Please add support for Radeon Kaveri / update the firmware package
package: firmware-linux-nonfree version: 0.43 severity: wishlist I have here: |processor : 3 |vendor_id : AuthenticAMD |cpu family : 21 |model : 48 |model name : AMD A10-7800 Radeon R7, 12 Compute Cores 4C+8G |00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] [1002:130f] and that one ask for the lower case firmware: |[drm] Loading kaveri Microcode |radeon :00:01.0: Direct firmware load for radeon/kaveri_pfp.bin failed with error -2 |radeon :00:01.0: Direct firmware load for radeon/kaveri_me.bin failed with error -2 |input: HD-Audio Generic Front Mic as /devices/pci:00/:00:14.2/sound/card1/input9 |radeon :00:01.0: Direct firmware load for radeon/kaveri_ce.bin failed with error -2 |radeon :00:01.0: Direct firmware load for radeon/kaveri_mec.bin failed with error -2 |radeon :00:01.0: Direct firmware load for radeon/kaveri_mec2.bin failed with error -2 |cik_cp: Failed to load firmware radeon/kaveri_mec2.bin |[drm:cik_init] *ERROR* Failed to load firmware! |radeon :00:01.0: Fatal error during GPU init and without it X won't come up. The console remains working. The lower case firmware is used in kernel since v3.17-rc1 and provided by the firmware git tree as of |commit f333bd435c0b6745cbc4fae3326725d77bf57c82 |Author: Alex Deucher alexander.deuc...@amd.com |Date: Wed Aug 20 15:09:50 2014 -0400 | |radeon: add updated firmware for radeon GPUs and updated later in |commit 78535e88bfb95e2f50afb6f9e728df0fbec2cddc |Author: Oded Gabbay oded.gab...@amd.com |Date: Mon Dec 22 13:26:44 2014 +0200 | |radeon: add updated firmware for kaveri (radeon GPU) I just installed the firmware from git repo and X comes up. There is fallback support for some chips but not for Kaveri. Sebastian -- 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/20150309113437.ga6...@breakpoint.cc
Bug#746232: 3.2.57-rt: rcu_preempt detected stalls at boot
* Alexandra N. Kossovsky | 2014-05-15 12:58:25 [+0400]: you seem to have have Xeon / i7. Can't it run x8664 / amd64? I have no idea what is going wrong here except that something is preventing rcu from running. Sebastian -- 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/20150216145826.gd21...@linutronix.de
Bug#723180: [PATCH] Revert x86: Disable IST stacks for debug/int 3/stack fault for PREEMPT_RT
* Andi Kleen | 2014-01-04 19:18:07 [+0100]: On Fri, Jan 03, 2014 at 02:55:48PM +0100, Sebastian Andrzej Siewior wrote: where do I start. Let me explain what is going on here. The code sequence Yes the IST stacks are needed for correctness, even in more cases than the example below. You cannot just disable them, just because you don't like them. Andi, you were the Author of that patch. I plan to migrate from the IST stack to the kernel stack so I can enable preemption. This is he case on 32bit. You mention more cases than this. Could you please give me some examples so I can consider them? -Andi Sebastian -- 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/20140106113230.ga25...@linutronix.de
Bug#723180: [PATCH] Revert x86: Disable IST stacks for debug/int 3/stack fault for PREEMPT_RT
where do I start. Let me explain what is going on here. The code
sequence
| pushf
| pop%edx
| or $0x1,%dh
| push %edx
| mov$0xe0,%eax
| popf
| sysenter
triggers the bug. On 64bit kernel we see the double fault (with 32bit and
64bit userland) and on 32bit kernel there is no problem. The reporter said
that double fault does not happen on 64bit kernel with 64bit userland and
this is because in that case the VDSO uses the syscall interface instead
of sysenter.
The bug. popf loads the flags with the TF bit set which enables
single stepping and this leads to a debug exception. Usually on 64bit
we have a special IST stack for the debug exception. Due to patch [0] we
do not use the IST stack but the kernel stack instead. On 64bit the
sysenter instruction starts in kernel with the stack address NULL. The
code sequence above enters the debug exception (TF flag) after the
sysenter instruction was executed which sets the stack pointer to NULL
and we have a fault (it seems that the debug exception saves some bytes
on the stack).
To fix the double fault I'm going to drop patch [0]. It is completely
pointless. In do_debug() and do_stack_segment() we disable preemption
which means the task can't leave the CPU. So it does not matter if we run
on IST or on kernel stack.
There is a patch [1] which drops preempt_disable() call for a 32bit
kernel but not for 64bit so there should be no regression.
And [1] seems valid even for this code sequence. We enter the debug
exception with a 256bytes long per cpu stack and migrate to the kernel
stack before calling do_debug().
[0] x86-disable-debug-stack.patch
[1] fix-rt-int3-x86_32-3.2-rt.patch
Reported-by: Brian Silverman bsilver16...@gmail.com
Cc: Andi Kleen a...@firstfloor.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/x86/include/asm/page_64_types.h | 21 ++---
arch/x86/kernel/cpu/common.c | 2 --
arch/x86/kernel/dumpstack_64.c | 4
3 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/x86/include/asm/page_64_types.h
b/arch/x86/include/asm/page_64_types.h
index 695e04d..43dcd80 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -14,21 +14,12 @@
#define IRQ_STACK_ORDER 2
#define IRQ_STACK_SIZE (PAGE_SIZE IRQ_STACK_ORDER)
-#ifdef CONFIG_PREEMPT_RT_FULL
-# define STACKFAULT_STACK 0
-# define DOUBLEFAULT_STACK 1
-# define NMI_STACK 2
-# define DEBUG_STACK 0
-# define MCE_STACK 3
-# define N_EXCEPTION_STACKS 3 /* hw limit: 7 */
-#else
-# define STACKFAULT_STACK 1
-# define DOUBLEFAULT_STACK 2
-# define NMI_STACK 3
-# define DEBUG_STACK 4
-# define MCE_STACK 5
-# define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
-#endif
+#define STACKFAULT_STACK 1
+#define DOUBLEFAULT_STACK 2
+#define NMI_STACK 3
+#define DEBUG_STACK 4
+#define MCE_STACK 5
+#define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
#define PUD_PAGE_SIZE (_AC(1, UL) PUD_SHIFT)
#define PUD_PAGE_MASK (~(PUD_PAGE_SIZE-1))
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c0dcf06..2793d1f 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1105,9 +1105,7 @@ DEFINE_PER_CPU(struct task_struct *, fpu_owner_task);
*/
static const unsigned int exception_stack_sizes[N_EXCEPTION_STACKS] = {
[0 ... N_EXCEPTION_STACKS - 1]= EXCEPTION_STKSZ,
-#if DEBUG_STACK 0
[DEBUG_STACK - 1] = DEBUG_STKSZ
-#endif
};
static DEFINE_PER_CPU_PAGE_ALIGNED(char, exception_stacks
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index 52b4bcd..addb207 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -21,14 +21,10 @@
(N_EXCEPTION_STACKS + DEBUG_STKSZ/EXCEPTION_STKSZ - 2)
static char x86_stack_ids[][8] = {
-#if DEBUG_STACK 0
[ DEBUG_STACK-1 ] = #DB,
-#endif
[ NMI_STACK-1 ] = NMI,
[ DOUBLEFAULT_STACK-1 ] = #DF,
-#if STACKFAULT_STACK 0
[ STACKFAULT_STACK-1] = #SS,
-#endif
[ MCE_STACK-1 ] = #MC,
#if DEBUG_STKSZ EXCEPTION_STKSZ
[ N_EXCEPTION_STACKS ...
--
1.8.5.2
--
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/20140103135548.ga6...@linutronix.de
Bug#723180: Double fault when single-stepping compat task with PREEMPT_RT
On 09/25/2013 03:24 PM, Ben Hutchings wrote:
On Tue, 2013-09-24 at 13:43 -0700, Brian Silverman wrote: [...]
I got down to a really simple program that reproduces this bug:
#include sys/syscall.h #include unistd.h int main() { // I've
tried SYS_getpid, SYS_write, and SYS_read here too.
syscall(SYS_gettid); }
Brian, thank you for this excellent stripped down test case.
I think I know what is going on, will dig more later.
Ben.
Sebastian
--
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/52ae0419.3050...@linutronix.de
Bug#593340: linux-2.6: please add new Debian arch: powerpcspe
* Ben Hutchings | 2012-06-02 18:55:17 [+0100]: Sorry we haven't done anything about this. No worries :) Are you still working on powerpcspe? Can you provide a patch suitable No, I dropped the ball. for the current version in sid or experimental? I haven't seen much progress here from Kyle or his team at Boeing. I guess they don't care anymore. That said, I'm perfectly fine if you close the bug as-it if you don't see any patches here within next one or two weeks. Ben. Sebastian -- 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/20120603182602.GA15775@kibibi
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
* Thus spake Alexander Clouter (a...@digriz.org.uk): I have just been tasked with putting together an active-active IPsec VPN concentrator (with a need to use AES-SHA1 it seems) and I was hoping to use the OpenRD's (and mv_cesa). Have you got a patch I can test that fixes things for SHA1? The patch below should work around the problem by not using it. You could try the kernel from backports. If I remember correctly than it seems that the later kernel passes one big chunk instead of three requests (init, update, fin). If that works out for then the only problem are fragmanted packets. diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c index 3cf303e..f556a71 100644 --- a/drivers/crypto/mv_cesa.c +++ b/drivers/crypto/mv_cesa.c @@ -1062,7 +1062,7 @@ static int mv_probe(struct platform_device *pdev) Could not register aes-cbc driver\n); goto err_unreg_ecb; } - +#if 0 ret = crypto_register_ahash(mv_sha1_alg); if (ret == 0) cpg-has_sha1 = 1; @@ -1076,7 +1076,7 @@ static int mv_probe(struct platform_device *pdev) printk(KERN_WARNING MV_CESA Could not register hmac-sha1 driver\n); } - +#endif return 0; err_unreg_ecb: crypto_unregister_alg(mv_aes_alg_ecb); Cheers Sebastian -- 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/20110808204638.ga10...@breakpoint.cc
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
* Alexander Clouter | 2011-06-08 09:54:58 [+]: Whilst deploying IPsec (with strongswan-ike2) I ran into a complication[1] that causes mv_cesa to spin the CPU when the system receives an IPsec ESP packet; it seems to be able to send traffic (before the CPU spin) as a ICMP Echo request (a la pin) out from the system out is okay, until the ICMP Reply comes back. The packet never 'arrives' as far as userspace is concerned and the only way to stop the CPU spinning is a reboot. I've been working on that and forgot about it in the meantime. The problem is that incremental sha1 checksum are wrong i.e. the previous state is ignored by the hardware. Kernel's auto-test droppped an error message which disappeared in later a kernel so I assumed that it was fixed. This was not case but oldconfig disabled the algorithm test. Sebastian -- 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/20110608113810.ga22...@chamillionaire.breakpoint.cc
Bug#610589: regression: broken hibernate after upgrade to linux-image-2.6.32-5-686 (2.6.32-30)
* Sebastian Andrzej Siewior | 2011-02-02 21:54:44 [+0100]: * Andrey Tataranovich | 2011-01-20 10:55:51 [+0200]: After upgrade linux-image-2.6.32-5-686 to 2.6.32-30, completely broken hibernate on my laptop. I using pm-hibernate from pm-utils (on top of uswsusp). I think this bug related Now, I rebuilt v2.6.32-30 and the only change made I was: * drop drm/i915: Free hardware status page on unload when physically mapped. * drop drm/i915/overlay: Ensure that the reg_bo is in the GTT prior to writing. The kernel I made is available at [0]. Do you mind testing it or rebuilding it yourself so I/we know if this bug is a the same as #611750? [0] http://download.breakpoint.cc/deb_bug_611750/ Sebastian -- 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/20110210170702.ga26...@chamillionaire.breakpoint.cc
Bug#611750:
* Paolo Casaschi | 2011-02-09 15:12:31 [+]: Same symptoms on an MSI Wind U100 netbook: everything else works other than resume from hibernate which fails most of the times (more on battery than on AC power) Havent tried to rebuild the kernel without the offending patch though. If you trust me enough, I have mine at [0] if you want to test it. [0] http://download.breakpoint.cc/deb_bug_611750/ Sebastian -- 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/20110209153317.ga15...@chamillionaire.breakpoint.cc
Bug#610589: regression: broken hibernate after upgrade to linux-image-2.6.32-5-686 (2.6.32-30)
* Andrey Tataranovich | 2011-01-20 10:55:51 [+0200]: Package: linux-2.6 Version: 2.6.32-30 Severity: normal Tags: squeeze upstream After upgrade linux-image-2.6.32-5-686 to 2.6.32-30, completely broken hibernate on my laptop. I using pm-hibernate from pm-utils (on top of uswsusp). I think this bug related Not sure if this is the same Problem or something different. lspci says here: |00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) During resume I see Tux sleeping in a small resolution. Once the progress bar is at 100% the resolution changes to whatever I use and I still see Tux but this time it does not fill the screen anymore. A few seconds after that the screen gets black due to xscreensaver (Yes I use X). This was the case until 2.6.32-29. Since 2.6.32-30 tux does not disapear and I can't enter X. I still see tux and my X mouse cursor moves within this image. Changing the terminal does not really work: I get to the framebuffer (CTRL+ALT+F1) but the tux image is still there. Switching back to X does not change a thing (it is still black). Executing xrandr -d :0.0 -q makes the TuX image disappear however I still can't access my X session. The only thing that works so far is killing X and restart it. This is a regression since 2.6.32-29 (installing it fixes the problem). Now, I rebuilt v2.6.32-30 and the only change made I was: * drop drm/i915: Free hardware status page on unload when physically mapped. * drop drm/i915/overlay: Ensure that the reg_bo is in the GTT prior to writing. Both of them were by maximilian so that is why you end up in To: :) Any idea how we fix this? Sebastian -- 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/20110202205444.ga18...@chamillionaire.breakpoint.cc
Bug#593340: linux-2.6: please add new Debian arch: powerpcspe
Here is version two of the patch including following changes:
- rebased against trunk
- removed initramfs-uimage-format
- reusing powerpc's config. All FB driver which are =y are switched to
=m
- # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set is gone
- the dtb package is gone. The kernel image includes _all_ .dtb files.
- drop the dependency on device-tree-compiler und use the in-kernel-tree
binary
diff --git a/debian/config/defines b/debian/config/defines
index c1d23d9..fe32363 100644
--- a/debian/config/defines
+++ b/debian/config/defines
@@ -13,6 +13,7 @@ arches:
mips
mipsel
powerpc
+ powerpcspe
s390
sh4
sparc
diff --git a/debian/config/powerpcspe/config b/debian/config/powerpcspe/config
new file mode 100644
index 000..89a35ba
--- /dev/null
+++ b/debian/config/powerpcspe/config
@@ -0,0 +1,60 @@
+CONFIG_PPC_85xx=y
+CONFIG_E500=y
+CONFIG_BOOKE=y
+CONFIG_FSL_BOOKE=y
+CONFIG_SPE=y
+CONFIG_MPC8536_DS=y
+CONFIG_MPC85xx_DS=y
+# CONFIG_CPU_FREQ is not set
+CONFIG_PPC_INDIRECT_PCI=y
+CONFIG_FSL_PCI=y
+CONFIG_PCI_DOMAINS=y
+CONFIG_PCI_SYSCALL=y
+CONFIG_PCIEPORTBUS=y
+CONFIG_PCIEAER=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_LEGACY=y
+CONFIG_MTD=y
+CONFIG_MTD_CHAR=m
+CONFIG_MTD_OF_PARTS=m
+CONFIG_MTD_BLOCK=m
+CONFIG_MTD_CFI=m
+CONFIG_MTD_JEDECPROBE=m
+CONFIG_MTD_CFI_INTELEXT=m
+CONFIG_MTD_CFI_AMDSTD=m
+CONFIG_MTD_CFI_STAA=m
+CONFIG_MTD_CFI_UTIL=m
+CONFIG_MTD_PHYSMAP_OF=m
+CONFIG_SATA_FSL=m
+CONFIG_FSL_PQ_MDIO=m
+CONFIG_GIANFAR=m
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_BOOKE_WDT=y
+CONFIG_I2C_MPC=m
+CONFIG_SPI_MPC8xxx=m
+CONFIG_AGP=m
+# CONFIG_FB_OF is not set
+CONFIG_FB_FSL_DIU=m
+CONFIG_FB_CT65550=m
+CONFIG_FB_NVIDIA=m
+CONFIG_FB_MATROX=m
+CONFIG_FB_MACMODES=m
+CONFIG_FB_ATY128=m
+CONFIG_FB_ATY=m
+CONFIG_FB_RADEON=m
+CONFIG_FB_SIS=m
+CONFIG_FB_VOODOO1=m
+# CONFIG_LOGO is not set
+CONFIG_FRAMEBUFFER_CONSOLE=m
+CONFIG_EDAC=y
+CONFIG_EDAC_MM_EDAC=y
+CONFIG_EDAC_MPC85XX=y
+CONFIG_USB=m
+CONFIG_USB_EHCI_HCD=m
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
+CONFIG_USB_EHCI_FSL=y
+CONFIG_USB_EHCI_HCD_PPC_OF=y
+CONFIG_CRYPTO_DEV_TALITOS=m
+CONFIG_RCU_TORTURE_TEST=m
diff --git a/debian/config/powerpcspe/config.powerpcspe-smp
b/debian/config/powerpcspe/config.powerpcspe-smp
new file mode 100644
index 000..7894f43
--- /dev/null
+++ b/debian/config/powerpcspe/config.powerpcspe-smp
@@ -0,0 +1,5 @@
+CONFIG_HIGHMEM=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
+CONFIG_PM_SLEEP_SMP=y
+CONFIG_IRQ_ALL_CPUS=y
diff --git a/debian/config/powerpcspe/defines b/debian/config/powerpcspe/defines
new file mode 100644
index 000..48c3888
--- /dev/null
+++ b/debian/config/powerpcspe/defines
@@ -0,0 +1,34 @@
+[base]
+flavours:
+ powerpcspe
+ powerpcspe-smp
+kernel-arch: powerpc
+compiler: gcc-4.4
+
+[powerpcspe_base]
+class: Book-E Freescale
+longclass: Freescale's Book-E
+
+[powerpcspe_build]
+image-file: arch/powerpc/boot/uImage
+
+[powerpcspe_image]
+depends: uboot-mkimage
+configs: powerpc/config powerpcspe/config
+
+[powerpcspe_description]
+hardware: uniprocessor 32-bit FSL book-E PowerPC
+
+[powerpcspe-smp_base]
+class: Book-E Freescale
+longclass: Book-E with Freescale's changes
+
+[powerpcspe-smp_build]
+image-file: arch/powerpc/boot/uImage
+
+[powerpcspe-smp_image]
+depends: uboot-mkimage
+configs: powerpc/config powerpcspe/config powerpcspe/config.powerpcspe-smp
+
+[powerpcspe-smp_description]
+hardware: multiprocessor 32-bit FSL book-E PowerPC
diff --git a/debian/rules.real b/debian/rules.real
index a782735..91858ab 100644
--- a/debian/rules.real
+++ b/debian/rules.real
@@ -39,7 +39,7 @@ MAKE_PERF_VARS = prefix=/usr NO_PERL=1 V=2
#
binary-arch-arch: install-headers_$(ARCH)
binary-arch-arch: install-libc-dev_$(ARCH)
-ifneq ($(filter alpha amd64 armel hppa i386 powerpc s390 sh4 sparc
sparc64,$(ARCH)),)
+ifneq ($(filter alpha amd64 armel hppa i386 powerpc powerpcspe s390 sh4 sparc
sparc64,$(ARCH)),)
binary-arch-arch: install-tools_$(ARCH)
endif
binary-arch-featureset: install-headers_$(ARCH)_$(FEATURESET)
@@ -256,7 +256,7 @@ install-headers_$(ARCH)_$(FEATURESET)_$(FLAVOUR):
$(STAMPS_DIR)/build_$(ARCH)_$(
cp -a $(SOURCE_DIR)/{.config,.kernel*,Module.symvers,include} $(DIR)
cp -a $(SOURCE_DIR)/arch/$(KERNEL_ARCH)/kernel/asm-offsets.s
$(DIR)/arch/$(KERNEL_ARCH)/kernel
-ifeq ($(ARCH),powerpc)
+ifneq ($(filter powerpc powerpcspe,$(ARCH)),)
if [ -f $(SOURCE_DIR)/arch/$(KERNEL_ARCH)/lib/crtsavres.o ]; then \
mkdir $(DIR)/arch/$(KERNEL_ARCH)/lib; \
cp -a $(SOURCE_DIR)/arch/$(KERNEL_ARCH)/lib/crtsavres.o
$(DIR)/arch/$(KERNEL_ARCH)/lib; \
@@ -386,6 +386,22 @@ install-image_mips_$(FEATURESET)_$(FLAVOUR)_plain_image \
install-image_mipsel_$(FEATURESET)_$(FLAVOUR)_plain_image:
install -m644 '$(DIR)/vmlinux' $(INSTALL_DIR)/vmlinux-$(REAL_VERSION)
+install-image_powerpcspe_$(FEATURESET)_$(FLAVOUR)_plain_image:
SOURCE_DIR=$(BUILD_DIR)/source
+install-image_powerpcspe_$(FEATURESET)_$(FLAVOUR)_plain_image:
Bug#593340: linux-2.6: please add new Debian arch: powerpcspe
Package: linux-2.6
Version: 2.6.32-20
Severity: wishlist
Tags: patch sid
User: debian-powerpc...@breakpoint.cc
Usertags: powerpcspe
This patch adds support for powerpcspe. The config activates a few
drivers and 85xx board. It was tested on top of the unstable svn
branch on mpc8536ds. SMP support is for mpc8572ds.
The boot loader expects us give it a kernel and ramdisk with an uImage
header around it. The compression is only important for the kernel as
the boot loader only decompresses the kernel. The ramdisk gets only its
uImage header removed and passed as it.
Since this image is also used by the D-I, the kernel image depends on
the just introduced linux-devicetree package which provides machine
descriptions for the individual boards. After an installation we will
have the kernel, initrd and device tree in proper shape. This means we
can pass it to the boot loader and boot. The boot loader has support for
SATA and TFTP so I guess we don't need any further hacks.
Sebastian
From 7bb5f1c7591def3f76cdf07e6fdd616d1000464b Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior bige...@linutronix.de
Date: Mon, 16 Aug 2010 10:13:26 +0200
Subject: [PATCH] linux-2.6: add support for powerpcspe
This patch adds support for powerpcspe. The config activates a few
drivers and 85xx board. It was tested on top of the unstable svn
branch on mpc8536ds. SMP support is for mpc8572ds.
The boot loader expects us give it a kernel and ramdisk with an uImage
header around it. The compression is only important for the kernel as
the boot loader only decompresses the kernel. The ramdisk gets only its
uImage header removed and passed as it.
Since this image is also used by the D-I, the kernel image depends on
the just introduced linux-devicetree package which provides machine
descriptions for the individual boards. After an installation we will
have the kernel, initrd and device tree in proper shape. This means we
can pass it to the boot loader and boot. The boot loader has support for
SATA and TFTP so I guess we don't need any further hacks.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
debian/bin/initramfs-uimage-format | 30 ++
debian/config/defines |2 +
debian/config/powerpcspe/config| 51
debian/config/powerpcspe/config.powerpcspe-smp |4 ++
debian/config/powerpcspe/defines | 32 +++
debian/rules |1 +
debian/rules.real | 45 -
debian/templates/control.main.in | 12 +-
debian/templates/control.source.in |2 +-
9 files changed, 175 insertions(+), 4 deletions(-)
create mode 100644 debian/bin/initramfs-uimage-format
create mode 100644 debian/config/powerpcspe/config
create mode 100644 debian/config/powerpcspe/config.powerpcspe-smp
create mode 100644 debian/config/powerpcspe/defines
diff --git a/debian/bin/initramfs-uimage-format
b/debian/bin/initramfs-uimage-format
new file mode 100644
index 000..459b231
--- /dev/null
+++ b/debian/bin/initramfs-uimage-format
@@ -0,0 +1,30 @@
+#!/bin/sh
+set -e
+
+# Script is called by kernel postinst with
+# version
+# Where version is upstream version. It will create an uImage header around
+# the freshly created initrd.
+#
+if [ -n $1 ]; then
+ version=$1
+ initrd=/boot/initrd.img-${version}
+else
+ echo Need version as argument
+ exit 1
+fi
+
+if [ ! -f ${initrd} ]; then
+ echo Can't find ${initrd}.
+ exit 1
+fi
+
+echo Creating new ${file}.uImage
+tmp=$(tempfile --prefix=initrd-upgrade)
+mkimage -A ppc -O linux -T ramdisk -C gzip -d ${initrd} ${tmp}
+if [ -e ${initrd}.uImage ]; then
+ echo backup of ${initrd}.uImage.
+ mv ${initrd}.uImage ${initrd}.uImage.bak
+fi
+mv $tmp ${initrd}.uImage
+echo New ${initrd}.uImage is ready
diff --git a/debian/config/defines b/debian/config/defines
index e2da5b0..505b9bd 100644
--- a/debian/config/defines
+++ b/debian/config/defines
@@ -41,6 +41,7 @@ arches:
mips
mipsel
powerpc
+ powerpcspe
s390
sh4
sparc
@@ -74,6 +75,7 @@ initramfs-tools: update-initramfs
[relations]
gcc-4.3: gcc-4.3
+gcc-4.4: gcc-4.4
initramfs-fallback: linux-initramfs-tool
initramfs-tools: initramfs-tools (= 0.55)
util-vserver: util-vserver (= 0.30.215)
diff --git a/debian/config/powerpcspe/config b/debian/config/powerpcspe/config
new file mode 100644
index 000..015c6d9
--- /dev/null
+++ b/debian/config/powerpcspe/config
@@ -0,0 +1,51 @@
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_PPC_85xx=y
+CONFIG_E500=y
+CONFIG_BOOKE=y
+CONFIG_FSL_BOOKE=y
+CONFIG_SPE=y
+CONFIG_OPROFILE=m
+CONFIG_MPC8536_DS=y
+CONFIG_MPC85xx_DS=y
+# CONFIG_CPU_FREQ is not set
+CONFIG_PPC_INDIRECT_PCI=y
+CONFIG_FSL_PCI=y
+CONFIG_PCI=y
+CONFIG_PCI_DOMAINS=y
+CONFIG_PCI_SYSCALL=y
+CONFIG_PCIEPORTBUS=y
+CONFIG_PCIEAER=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_LEGACY=y
Bug#593340: linux-2.6: please add new Debian arch: powerpcspe
* Bastian Blank | 2010-08-17 13:25:05 [+0200]: Thanks for the quick response :) On Tue, Aug 17, 2010 at 01:04:13PM +0200, Sebastian Andrzej Siewior wrote: This have to be a patch against trunk. will redo. --- /dev/null +++ b/debian/bin/initramfs-uimage-format No, this belongs to the bootloader. Huh? The bootloader expects an uImage header around the initrd. So you want me to come up with a bootloader package which puts the uImage header around i.e. provides this script? @@ -74,6 +75,7 @@ initramfs-tools: update-initramfs [relations] gcc-4.3: gcc-4.3 +gcc-4.4: gcc-4.4 Already done. new file mode 100644 index 000..015c6d9 --- /dev/null +++ b/debian/config/powerpcspe/config Why can't you reuse powerpc/config? How does reuse work? A copy of the file or something like powerpc/config powerpcspe/config in the defines file? I think it could work. CONFIG_PPC_PMAC is for different platform/architecture. So I guess once it sees CONFIG_BOOKE it will drop the remaining thigs like RTAS, XMON or PMAC drivers. I would prefer not to have any FB devices built-in. Besides that, it looks only driver specific. @@ -0,0 +1,51 @@ +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set Why? I haven't done benchmarks on Os vs O2 I just prefer the latter. Giving the fact that I now have more modules as usual it would be probably better to go for the size. --- /dev/null +++ b/debian/config/powerpcspe/defines @@ -0,0 +1,32 @@ +[base] +flavours: + powerpcspe + powerpcspe-smp Why two? One with SMP support, the other without. SMP requires additional memory coherents and spinlocks are not removed in an UP boot as it is the case on x86 for instance. +$(STAMPS_DIR)/build-devicetree_$(ARCH): SOURCE_DIR=$(BUILD_DIR)/source +$(STAMPS_DIR)/build-devicetree_$(ARCH): DIR=$(BUILD_DIR)/build-devicetree_$(ARCH) +$(STAMPS_DIR)/build-devicetree_$(ARCH): $(STAMPS_DIR)/source +rm -rf $(DIR) +mkdir -p $(DIR) +for name in mpc8536ds mpc8572ds; do \ +dtc -O dtb -b 0 -p 1024 \ +-o $(DIR)/$$name-$(UPSTREAMVERSION).dtb \ +$(SOURCE_DIR)/arch/$(KERNEL_ARCH)/boot/dts/$$name.dts; \ +done +@$(stamp) No hardcoding. Why does this need to be seperate from the kernel? I wanted to avoid to build them all so picked two for now. Would you prefer a list or don't care build them all? I seperated them from the kernel image because they are the same in both kernal packages. Bastian Sebastian -- 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/20100817130632.gb12...@chamillionaire.breakpoint.cc
Kernel package for powerpcspe
Hello Kernel team, Currently I plan to come up with a kernel package for the powercpspe which is currently in debian-ports. I have a few questions: - what is the easy way to create the kernel config? I guess you don't use vim for that :) I've found a ruby script in an earlier svn revision but it is gone now. - what are the rules for out-of-tree patches? I guess patches which are merged upstream but not yet in the debian-kernel are okay, everything else is unlikely to be accepted. - the initrd has to have an uImage header around it. Currently I install a script to /etc/kernel/postinst.d/$(REAL_VERSION) to get this done during installation of the package. Is this okay or is something else prefered? - besides the kernel and initrd I have a device tree which contains all the relevant device informations for a single board. Is it okay to throw them in at $(INSTALL_DIR)/$(BOARD)-$(REAL_VERSION).dtb? It is very convinient in the D-I case because after the install the user has everything in /boot. Sebastian -- 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/20100630093242.ga25...@chamillionaire.breakpoint.cc
Bug#585790: linux-image-2.6.32-5-kirkwood: Oops in mv_cesa
* Martin Michlmayr | 2010-06-20 14:26:22 [+0100]: The patches until 0328ac267 to 15d4dd3 are probably required. All of these changes seem pretty self-contained, so I'd like to go ahead and apply all of them to Debian's 2.6.32 package. Do you see any problems with this? No I don't, you should be able to take them. I could test the debian kernel with those patches on-top if you want me to. Sebastian -- 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/20100621180755.ga7...@chamillionaire.breakpoint.cc
Bug#571305: Swarm does not boot on .32 anymore.
* Martin Michlmayr | 2010-02-26 07:47:30 [-0500]: * Sebastian Andrzej Siewior sebast...@breakpoint.cc [2010-02-26 08:50]: can you get Ralf or David Daney to submit it for inclusion into the 2.6.32-stable series? It is allready there [0]. [0] http://git.kernel.org/?p=linux/kernel/git/ralf/linux.git;a=shortlog;h=refs/heads/linux-2.6.32-stable Ok, so this should be in the next stable update. Okay, so you were not talkin about Ralf's tree but about tree maintained by the stable-kernel team. Ups. I've sent it there now :) Sebastian -- 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/20100301125034.gb24...@chamillionaire.breakpoint.cc
Bug#571305: Swarm does not boot on .32 anymore.
* Martin Michlmayr | 2010-02-25 21:57:41 [-0500]: Note that even if this bug is fixed, there are other problems with the SWARM kernel: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404951 Yes. This bug is still there and I'm looking at this. Besides that the box runs fine so far. If you don't use the onboard IDE (let's say you have a SATA PCI card) then it is faster and you don't hit this problem. Sebatian -- 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/20100226075633.gb29...@chamillionaire.breakpoint.cc
Bug#524003: FTBFS on armel
tags 524003 + patch thanks. * Sebastian Andrzej Siewior | 2010-01-26 23:09:59 [+0100]: fine. I don't patch tag since the two dcache flushes don't look right and upstream did not apply it yet. We will see. It is in queued in -mm [0] for .33, will be backportable if nobody has a problem with it [1]. So we have patch now :) I'm curious what can be done about the dependency of tokyocabinet. It should depend on the kernel which has the patch because a user of the library might get wrong results if it is using a kernel without the patch on the affected architecture. However, there is no need to use a debian kernel so users without a debian kernel would get it pulled in. Plus even if the kernel is installed it is not necessary that this is the kernel which booted the system. [0] http://marc.info/?l=linux-mm-commitsm=126454582727638w=2 [1] http://lkml.org/lkml/2010/1/27/344 Sebastian -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524003: FTBFS on armel
reassign 524003 linux-2.6 2.6.32-5 tags 524003 - help thanks. * Pierre Habouzit | 2009-04-15 01:40:32 [+0200]: Hi Mikio, I'm the Debian maintainer of tokyocabinet, I wanted to report to you that tokyocabinet seems to have issues on armel (and also hppa). You can see the full build logs here: https://buildd.debian.org/fetch.cgi?pkg=tokyocabinetarch=armelver=1.4.14-2stamp=1239676884file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=tokyocabinetarch=hppaver=1.4.14-2stamp=1239662413file=logas=raw I've been looking at the ARM part and I can reproduce this here on my machine. The error message or that part where the test case stopped depends very much on the seed. With seed=0 or 1 (don't remember really) I got an infinite loop. So it looked to me for a while that the test code is buggy. Also comparing the seed with amd64 the armel seed is much higher. However nothing of this true :) I looks now that this a kernel bug. The patch at [0] which I attached seems to fix the issue and I was able to build the package on my arm box after applying the patch. I would be happy if someone could re-test this on ARM and on HPPA. I reassing to package to the kernel team since I thing the user space is fine. I don't patch tag since the two dcache flushes don't look right and upstream did not apply it yet. We will see. Date: Thu, 21 Jan 2010 13:07:57 +0800 Message-ID: 979dd0561001202107v4ddc1eb7xa59a7c16c452f...@mail.gmail.com Subject: [PATCH] Flush dcache before writing into page to avoid alias From: anfei zhou anfei.z...@gmail.com To: linux...@kvack.org, linux-ker...@vger.kernel.org Cc: Andrew Morton a...@linux-foundation.org, KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com, li...@arm.linux.org.uk, Jamie Lokier ja...@shareable.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-ow...@vger.kernel.org Precedence: bulk List-ID: linux-kernel.vger.kernel.org The cache alias problem will happen if the changes of user shared mapping is not flushed before copying, then user and kernel mapping may be mapped into two different cache line, it is impossible to guarantee the coherence after iov_iter_copy_from_user_atomic. So the right steps should be: flush_dcache_page(page); kmap_atomic(page); write to page; kunmap_atomic(page); flush_dcache_page(page); More precisely, we might create two new APIs flush_dcache_user_page and flush_dcache_kern_page to replace the two flush_dcache_page accordingly. Here is a snippet tested on omap2430 with VIPT cache, and I think it is not ARM-specific: int val = 0x; fd = open(abc, O_RDWR); addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); *(addr+0) = 0x; tmp = *(addr+0); *(addr+1) = 0x; write(fd, val, sizeof(int)); close(fd); The results are not always 0x 0x at the beginning as expected. Signed-off-by: Anfei anfei.z...@gmail.com --- fs/fuse/file.c |3 +++ mm/filemap.c |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/fs/fuse/file.c b/fs/fuse/file.c index c18913a..a9f5e13 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -828,6 +828,9 @@ static ssize_t fuse_fill_write_pages(struct fuse_req *req, if (!page) break; + if (mapping_writably_mapped(mapping)) + flush_dcache_page(page); + pagefault_disable(); tmp = iov_iter_copy_from_user_atomic(page, ii, offset, bytes); pagefault_enable(); diff --git a/mm/filemap.c b/mm/filemap.c index 96ac6b0..07056fb 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2196,6 +2196,9 @@ again: if (unlikely(status)) break; + if (mapping_writably_mapped(mapping)) + flush_dcache_page(page); + pagefault_disable(); copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes); pagefault_enable(); -- 1.6.3.1 [0] http://lkml.org/lkml/2010/1/21/3 Sebastian -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544905: closed by Bastian Blank wa...@debian.org (Bug#544905: fixed in linux-2.6 2.6.32~rc8-1~experimental.1)
* Daniel Schepler | 2009-11-25 11:47:07 [-0800]: I just tried building libsigsegv under this version of linux-image-2.6.32-rc8- amd64 and still got the same build failure. Yes, because the patch never made it into the kernel. The changelog says: | [ Ben Hutchings ] | * New upstream release candidate. | - signal: Fix alternate signal stack check (Closes: #544905) and this is not the case. I wrote earler [0] that the patch is in the TIP tree and _will_ be merged into Linus' tree. I should probably not have mention this part in order not cause any confusion what I obviously have done. However, the patch is now merged into Linus' tree [1] and it will show up in v2.6.33-rc1. Due to its stable tag, the patch should pop up v2.6.32.X series. In the meantime libsigsegfault upstream maintainer applied a duck tape patch [2] to pass the test which just lame IMHO. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=34;att=0;bug=544905 [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2a855dd01bc1539111adb7233f587c5c468732ac [2] http://git.savannah.gnu.org/cgit/libsigsegv.git/commit/?id=4f14ef87b2fba9718c1a88b9ed9ca7ba111d60da Sebastian -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: linux-2.6 piuparts error
* maximilian attems | 2009-11-17 11:10:46 [+0100]:
0m54.3s ERROR: FAIL: Package purging left files on system:
/etc/kernel-img.conf not owned
oh
so either it is a failure to generate such a file in postinst (as we
shouldn't really need it!?), or one would want to remove it on purge,
which opens another can of worms as this file is unowned in real boxes
and usualy created by d-i.
the best argument is that due to the convulated questions postinst
wanted to ask you in the past we had never reached that point of
generating this conffile in postinst.
What is the long term goal? Do you plan do to get rid of kernel-img.conf
and let the individual boot loader handle this kind of things?
You are changing the default behavior of palo here. However the values
are written very late. link_in_boot for instance is only evalueted at
the begin of the script. So it should not really matter for postinst at
least.
The do_symlink thing is only required by people that don't have their
setup right, isn't it? So grub refers to /vmlinuz but kernel itself is
not in / but in /boot. So if those people would fix their boxes we could
get rid of do_symlink for instance right?
diff --git a/linux-2.6/debian/templates/temp.image.plain/postinst
b/linux-2.6/debian/templates/temp.image.plain/postinst
index ae8c797..43dba4d 100755
--- a/linux-2.6/debian/templates/temp.image.plain/postinst
+++ b/linux-2.6/debian/templates/temp.image.plain/postinst
@@ -478,24 +478,10 @@ sub handle_missing_link {
die(Failed to copy . $realimageloc . $image_name to
. $image_dest . $kimage .\n);
}
- }
- else {
+ } else {
if (! $have_conffile) {
# current default
$do_symlink = Yes;
-
- if (open(CONF, $CONF_LOC)) {
-print CONF # Kernel Image management overrides\n;
-print CONF # See kernel-img.conf(5) for details\n;
-if ($loader =~ /palo/i) {
- print CONF link_in_boot = Yes\n;
- print CONF do_symlinks = Yes\n;
- print CONF relative_links = Yes\n;
- print CONF do_bootloader = No\n;
-}
-close CONF;
- }
- $have_conffile = Yes;
}
}
Sebastian
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544905: (no subject)
tags 544905 + patch
thanks
the patch attached has been added to the TIP tree [0] and will be merged
into Linus'.
[0]
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=commit;h=2a855dd01bc1539111adb7233f587c5c468732ac
Sebastian
Commit-ID: 2a855dd01bc1539111adb7233f587c5c468732ac
Gitweb: http://git.kernel.org/tip/2a855dd01bc1539111adb7233f587c5c468732ac
Author: Sebastian Andrzej Siewior sebast...@breakpoint.cc
AuthorDate: Sun, 25 Oct 2009 15:37:58 +0100
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Wed, 4 Nov 2009 18:19:12 +0100
signal: Fix alternate signal stack check
All architectures in the kernel increment/decrement the stack pointer
before storing values on the stack.
On architectures which have the stack grow down sas_ss_sp == sp is not
on the alternate signal stack while sas_ss_sp + sas_ss_size == sp is
on the alternate signal stack.
On architectures which have the stack grow up sas_ss_sp == sp is on
the alternate signal stack while sas_ss_sp + sas_ss_size == sp is not
on the alternate signal stack.
The current implementation fails for architectures which have the
stack grow down on the corner case where sas_ss_sp == sp.This was
reported as Debian bug #544905 on AMD64.
Simplified test case: http://download.breakpoint.cc/tc-sig-stack.c
The test case creates the following stack scenario:
0xn0300 stack top
0xn0200 alt stack pointer top (when switching to alt stack)
0xn01ff alt stack end
0xn0100 alt stack start == stack pointer
If the signal is sent the stack pointer is pointing to the base
address of the alt stack and the kernel erroneously decides that it
has already switched to the alternate stack because of the current
check for sp - sas_ss_sp sas_ss_size
On parisc (stack grows up) the scenario would be:
0xn0200 stack pointer
0xn01ff alt stack end
0xn0100 alt stack start = alt stack pointer base
(when switching to alt stack)
0xn stack base
This is handled correctly by the current implementation.
[ tglx: Modified for archs which have the stack grow up (parisc) which
would fail with the correct implementation for stack grows
down. Added a check for sp = current-sas_ss_sp which is
strictly not necessary but makes the code symetric for both
variants ]
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Cc: Oleg Nesterov o...@redhat.com
Cc: Roland McGrath rol...@redhat.com
Cc: Kyle McMartin k...@mcmartin.ca
Cc: sta...@kernel.org
LKML-Reference: 20091025143758.ga6...@chamillionaire.breakpoint.cc
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
include/linux/sched.h | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 75e6e60..0f67914 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2086,11 +2086,18 @@ static inline int is_si_special(const struct siginfo
*info)
return info = SEND_SIG_FORCED;
}
-/* True if we are on the alternate signal stack. */
-
+/*
+ * True if we are on the alternate signal stack.
+ */
static inline int on_sig_stack(unsigned long sp)
{
- return (sp - current-sas_ss_sp current-sas_ss_size);
+#ifdef CONFIG_STACK_GROWSUP
+ return sp = current-sas_ss_sp
+ sp - current-sas_ss_sp current-sas_ss_size;
+#else
+ return sp current-sas_ss_sp
+ sp - current-sas_ss_sp = current-sas_ss_size;
+#endif
}
static inline int sas_ss_flags(unsigned long sp)
[PATCH] postinst: get rid of reverse symlinks handling
maximilian suggested to grab an axe and rip the reverse symlinks handling out.
The man page for kernel-img.conf has no reference to it anymore.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
debian/rules.real |1 -
debian/templates/temp.image.plain/postinst | 60 +--
debian/templates/temp.image.plain/postrm |3 -
debian/templates/temp.image.plain/preinst |3 -
debian/templates/temp.image.plain/prerm|3 -
5 files changed, 3 insertions(+), 67 deletions(-)
diff --git a/debian/rules.real b/debian/rules.real
index 66bc700..056efee 100644
--- a/debian/rules.real
+++ b/debian/rules.real
@@ -396,7 +396,6 @@
install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_templates:
-e 's/=V/$(REAL_VERSION)/g' \
-e 's/=M//g' \
-e 's/=MD//g' \
- -e 's/=R//g' \
-e 's/=S//g' \
$$i $(PACKAGE_DIR)/DEBIAN/$$(basename $$i); \
done
diff --git a/debian/templates/temp.image.plain/postinst
b/debian/templates/temp.image.plain/postinst
index 2ac4a0b..1ae393a 100755
--- a/debian/templates/temp.image.plain/postinst
+++ b/debian/templates/temp.image.plain/postinst
@@ -29,7 +29,6 @@ $|=1;
my $version = =V;
my $link_in_boot = =IB; # Should be empty, mostly
my $no_symlink= =S; # Should be empty, mostly
-my $reverse_symlink = =R; # Should be empty, mostly
my $do_symlink= Yes; # target machine defined
my $do_boot_enable= Yes; # target machine defined
my $do_bootloader = Yes; # target machine defined
@@ -103,7 +102,6 @@ if (-r $CONF_LOC -f $CONF_LOC ) {
$do_symlink = if /do_symlinks\s*=\s*(no|false|0)\s*$/ig;
$no_symlink = if /no_symlinks\s*=\s*(no|false|0)\s*$/ig;
- $reverse_symlink = if /reverse_symlink\s*=\s*(no|false|0)\s*$/ig;
$link_in_boot= if /link_in_boot\s*=\s*(no|false|0)\s*$/ig;
$do_boot_enable = '' if /do_boot_enable\s*=\s*(no|false|0)\s*$/ig;
$relative_links = '' if /relative_links \s*=\s*(no|false|0)\s*$/ig;
@@ -118,7 +116,6 @@ if (-r $CONF_LOC -f $CONF_LOC ) {
$do_symlink = Yes if /do_symlinks\s*=\s*(yes|true|1)\s*$/ig;
$no_symlink = Yes if /no_symlinks\s*=\s*(yes|true|1)\s*$/ig;
- $reverse_symlink = Yes if /reverse_symlinks\s*=\s*(yes|true|1)\s*$/ig;
$link_in_boot= Yes if /link_in_boot\s*=\s*(yes|true|1)\s*$/ig;
$do_boot_enable = Yes if /do_boot_enable\s*=\s*(yes|true|1)\s*$/ig;
$do_bootloader = Yes if /do_bootloader\s*=\s*(yes|true|1)\s*$/ig;
@@ -342,12 +339,10 @@ sub move_p {
warn Move?: kimage=$kimage, image_dest=$image_dest, \n .
\timage_name=$image_name, src_dir=$src_dir if $DEBUG;
- if ($no_symlink || $reverse_symlink) {
+ if ($no_symlink) {
# we do not want links, yet we have a symbolic link here!
warn found a symbolic link in . $image_dest . $kimage \n .
even though no_symlink is defined\n if $no_symlink;
-warn found a symbolic link in . $image_dest . $kimage \n .
- even though reverse_symlink is defined\n if $reverse_symlink;
# make sure we change this state of affairs
$force_move = 1;
return $force_move;
@@ -503,14 +498,6 @@ sub handle_missing_link {
. $image_dest . $kimage .\n);
}
}
- elsif ($reverse_symlink) {
-my $ret = system(mv -f . $realimageloc . $image_name
- . $kimage);
-if ($ret) {
- die(Failed to move . $realimageloc . $image_name to
- . $image_dest . $kimage .\n);
-}
- }
else {
if (! $have_conffile) {
my $ret;
@@ -538,12 +525,6 @@ sub handle_missing_link {
my $Name = $image_name;
my $Link_Dest = $kimage;
-if ($reverse_symlink) {
- $Old = $image_dest;
- $New = $realimageloc;
- $Name = $kimage;
- $Link_Dest = $realimageloc . $image_name;
-}
if (test_relative ('Old Dir' = $Old,
'New Dir' = $New,
'Test File' = $Name)) {
@@ -560,7 +541,7 @@ sub handle_missing_link {
}
# This routine handles the rest of the cases, where the user has requested
-# non-traditional handling, like using cp, or reverse symlinks, or hard links.
+# non-traditional handling, like using cp or hard links.
sub handle_non_symlinks {
my $kimage = $_[0]; # Name of the symbolic link
my $image_dest = $_[1]; # The directory the links goes into
@@ -591,41 +572,6 @@ sub handle_non_symlinks {
##,
# case Two
#`
- elsif ($reverse_symlink) { # Maybe /$image_dest is on a dos system?
-my $ret = system(mv -f . $realimageloc . $image_name
- . $image_dest . $kimage);
-if ($ret) {
- if (-e $kimage.$$) {
-rename($kimage.$$, $kimage);
- }
- die(Failed to move . $realimageloc . $image_name to
- . $image_dest . $kimage .\n);
-}
-my $Old = $image_dest
Bug#555093: Missing kernel-img.conf makes a debian kernel not installable
Package: linux-2.6
Version: 2.6.31-1
Severity: normal
Tags: patch
There is no /etc/kernel-img.con on a fresh debootstrap sid. Installing a
kernel leads to:
|mikejones:/var/lib# dpkg --configure -a
|Setting up linux-image-2.6.31-1-amd64 (2.6.31-1) ...
|Running depmod.
|Running update-initramfs.
|update-initramfs: Generating /boot/initrd.img-2.6.31-1-amd64
|Error retreiving answer for
linux-image-2.6.31-1-amd64/postinst/create-kimage-link-2.6.31-1-amd64:
| linux-image-2.6.31-1-amd64/postinst/create-kimage-link-2.6.31-1-amd64 doesn't
exist at
| /var/lib/dpkg/info/linux-image-2.6.31-1-amd64.postinst line 522, STDIN line
3.
|dpkg: error processing linux-image-2.6.31-1-amd64 (--configure):
| subprocess installed post-installation script returned error exit status 9
As far as I understand debconf, there must be a template and input() for
${package_name}/postinst/create-kimage-link-$version in order to get a
value saved. Since I did not find it I guess that this can't work.
If the bootloader is palo than the answer is ignored anyway so the
question is not required there.
kernel-img.conf(5) says that do_symlinks defaults to yes.
This could also fix piuparts [0].
[0] http://piuparts.debian.org/sid/fail/linux-image-2.6.31-1-amd64_2.6.31-1.log
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
debian/templates/temp.image.plain/postinst | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/debian/templates/temp.image.plain/postinst
b/debian/templates/temp.image.plain/postinst
index 5e827de..d4063ef 100644
--- a/debian/templates/temp.image.plain/postinst
+++ b/debian/templates/temp.image.plain/postinst
@@ -514,28 +514,17 @@ sub handle_missing_link {
else {
if (! $have_conffile) {
my $ret;
- my $answer='';
$do_symlink = Yes;
- my $question = ${package_name}/postinst/create-kimage-link-$version;
- ($ret,$answer) = get($question);
- die Error retreiving answer for $question: $answer if $ret;
-
- $answer =~ s/^\s+//;
- $answer =~ s/\s+$//;
- $do_symlink = No if $answer =~ /^(f|n)/i;
-
if (open(CONF, $CONF_LOC)) {
print CONF # Kernel Image management overrides\n;
print CONF # See kernel-img.conf(5) for details\n;
if ($loader =~ /palo/i) {
print CONF link_in_boot = Yes\n;
- print CONF do_symlinks = Yes\n;
print CONF relative_links = Yes\n;
print CONF do_bootloader = No\n;
-} else {
- print CONF do_symlinks = $do_symlink\n;
}
+print CONF do_symlinks = $do_symlink\n;
close CONF;
}
$have_conffile = Yes;
--
1.6.5.2
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
