Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting
On Wed, 2014-01-15 at 07:26 +0100, Hardy Griech wrote: > Is it possible to take back the testing status (reverting it to > experimental) of the 3.12-1-kirkwood kernel until the issue has been fixed? The Debian archive infrastructure does not support this AFAIK. Ian. signature.asc Description: This is a digitally signed message part
Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting
On Tue, 2014-01-14 at 22:47 +, Ian Campbell wrote: > It's late so I'm going to set a build going of v3.12 with the above > reverted and see how it goes in the morning before putting together a > report for upstream. v3.12 with the following revert works for me. I'm going to try v3.13-rc8 before reporting upstream. commit 19d60c0e669fb92e187ae54558f9b45c2cba5584 Author: Ian Campbell Date: Tue Jan 14 22:47:44 2014 + Revert "ARM: kirkwood: convert to DT irqchip and clocksource" This reverts commit 2326f04321a9aec591c1d159b3a9d12c2bf89438. Conflicts: arch/arm/mach-kirkwood/Kconfig diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig index fe8319a..c11fcce 100644 --- a/arch/arm/mach-kirkwood/Kconfig +++ b/arch/arm/mach-kirkwood/Kconfig @@ -2,32 +2,67 @@ if ARCH_KIRKWOOD menu "Marvell Kirkwood Implementations" -config KIRKWOOD_LEGACY - bool - config MACH_D2NET_V2 bool "LaCie d2 Network v2 NAS Board" - select KIRKWOOD_LEGACY help Say 'Y' here if you want your kernel to support the LaCie d2 Network v2 NAS. +config MACH_DOCKSTAR + bool "Seagate FreeAgent DockStar" + help + Say 'Y' here if you want your kernel to support the + Seagate FreeAgent DockStar. + +config MACH_ESATA_SHEEVAPLUG + bool "Marvell eSATA SheevaPlug Reference Board" + help + Say 'Y' here if you want your kernel to support the + Marvell eSATA SheevaPlug Reference Board. + +config MACH_GURUPLUG + bool "Marvell GuruPlug Reference Board" + help + Say 'Y' here if you want your kernel to support the + Marvell GuruPlug Reference Board. + +config MACH_INETSPACE_V2 + bool "LaCie Internet Space v2 NAS Board" + help + Say 'Y' here if you want your kernel to support the + LaCie Internet Space v2 NAS. + +config MACH_MV88F6281GTW_GE + bool "Marvell 88F6281 GTW GE Board" + help + Say 'Y' here if you want your kernel to support the + Marvell 88F6281 GTW GE Board. + config MACH_NET2BIG_V2 bool "LaCie 2Big Network v2 NAS Board" - select KIRKWOOD_LEGACY help Say 'Y' here if you want your kernel to support the LaCie 2Big Network v2 NAS. config MACH_NET5BIG_V2 bool "LaCie 5Big Network v2 NAS Board" - select KIRKWOOD_LEGACY help Say 'Y' here if you want your kernel to support the LaCie 5Big Network v2 NAS. +config MACH_NETSPACE_MAX_V2 + bool "LaCie Network Space Max v2 NAS Board" + help + Say 'Y' here if you want your kernel to support the + LaCie Network Space Max v2 NAS. + +config MACH_NETSPACE_V2 + bool "LaCie Network Space v2 NAS Board" + help + Say 'Y' here if you want your kernel to support the + LaCie Network Space v2 NAS. + config MACH_OPENRD - select KIRKWOOD_LEGACY bool config MACH_OPENRD_BASE @@ -53,28 +88,30 @@ config MACH_OPENRD_ULTIMATE config MACH_RD88F6192_NAS bool "Marvell RD-88F6192-NAS Reference Board" - select KIRKWOOD_LEGACY help Say 'Y' here if you want your kernel to support the Marvell RD-88F6192-NAS Reference Board. config MACH_RD88F6281 bool "Marvell RD-88F6281 Reference Board" - select KIRKWOOD_LEGACY help Say 'Y' here if you want your kernel to support the Marvell RD-88F6281 Reference Board. +config MACH_SHEEVAPLUG + bool "Marvell SheevaPlug Reference Board" + help + Say 'Y' here if you want your kernel to support the + Marvell SheevaPlug Reference Board. + config MACH_T5325 bool "HP t5325 Thin Client" - select KIRKWOOD_LEGACY help Say 'Y' here if you want your kernel to support the HP t5325 Thin Client. config MACH_TS219 bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS" - select KIRKWOOD_LEGACY help Say 'Y' here if you want your kernel to support the QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and @@ -82,7 +119,6 @@ config MACH_TS219 config MACH_TS41X bool "QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo NAS" - select KIRKWOOD_LEGACY help Say 'Y' here if you want your kernel to support the QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo @@ -93,9 +129,6 @@ comment "Device tree entries" config ARCH_KIRKWOOD_DT bool "Marvell Kirkwood Flattened Device Tree" select KIRKWOOD_CLK - select OF_IRQ - select ORION_IRQCHIP - select ORION_TIMER select POWER_SUPPLY select POWER_RESET select POWER_RESET_GPIO diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile index d1f8e3d..1c3a6fe 100644 --- a/arch/arm/mach-kirkwood/Makefile +++ b/arc
Processed: reassign 735254 to linux, forcibly merging 735172 735254
Processing commands for cont...@bugs.debian.org: > reassign 735254 linux Bug #735254 [src:linux] flash-kernel: QNAP TS-212 doesn't boot with 3.12-1-kirkwood and flash-kernel 3.12 Bug reassigned from package 'src:linux' to 'linux'. Ignoring request to alter found versions of bug #735254 to the same values previously set Ignoring request to alter fixed versions of bug #735254 to the same values previously set > forcemerge 735172 735254 Bug #735172 [linux] linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting Bug #735254 [linux] flash-kernel: QNAP TS-212 doesn't boot with 3.12-1-kirkwood and flash-kernel 3.12 Severity set to 'important' from 'critical' There is no source info for the package 'linux' at version '3.12.6-2' with architecture '' Unable to make a source version for version '3.12.6-2' Marked as found in versions 3.12.6-2. Merged 735172 735254 > thanks Stopping processing here. Please contact me if you need assistance. -- 735172: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735172 735254: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735254 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.138977447629515.transcr...@bugs.debian.org
Bug#735172: v3.12 regression from "ARM: kirkwood: convert to DT irqchip and clocksource" on non-DT kirkwood platforms
On 01/15/14 09:40, Ian Campbell wrote: Debian kernel's have been suffering a hang on boot on kirkwood platforms since 3.12, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735172. The issue has been seen on various QNAP TS platforms, mine is a TS-419 but TS-119 and TS-212's have also been seen to fail. In all cases this is using the legacy board file based support not the DT support (which is only for TS-219 so far in any case AFAIK, I am not using Andrew Lunn's DT patches for TS-41x). Ian, thanks for the detailed report below. I quickly checked your .config and saw you have CONFIG_ARCH_KIRKWOOD_DT=y although I understand you are not booting DT here. There may be some interference with both non-DT/DT compiled in, I'll check that later. The bootlogs are below or in the bug. It stops after "Console: colour dummy device 80x30", I think next would normally be the BogoMIPS/calibrate_delay output. That would indicate the timer (clocksource) or irq (irqchip) is not running correctly. Again, that could be non-DT and DT fighting for it. I'll investigate that. In the meantime, can you recompile your kernel and set CONFIG_ARCH_KIRKWOOD_DT=n ? Sebastian I bisected it down to: commit 2326f04321a9aec591c1d159b3a9d12c2bf89438 Author: Sebastian Hesselbarth Date: Tue Jul 2 15:15:07 2013 +0200 ARM: kirkwood: convert to DT irqchip and clocksource With recent support for true irqchip and clocksource drivers for Orion SoCs, now make use of it on DT enabled Kirkwood boards. This also introduces a new Kconfig option for legacy (non-DT) Kirkwood where old code is moved out to and polishes DT board file a little bit. Signed-off-by: Sebastian Hesselbarth Signed-off-by: Jason Cooper and reverting this on top of v3.12 allows the platform to boot successfully. I've also reproduced with v3.13-rc8 and the revert was not so trivial there, but I think I've done it right and it corrects the problem. -- 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/52d651cd.5020...@gmail.com
Bug#735172: v3.12 regression from "ARM: kirkwood: convert to DT irqchip and clocksource" on non-DT kirkwood platforms
On Wed, 2014-01-15 at 10:15 +0100, Sebastian Hesselbarth wrote: > On 01/15/14 09:40, Ian Campbell wrote: > > The bootlogs are below or in the bug. It stops after "Console: colour > > dummy device 80x30", I think next would normally be the > > BogoMIPS/calibrate_delay output. > > That would indicate the timer (clocksource) or irq (irqchip) is not > running correctly. Again, that could be non-DT and DT fighting for it. > I'll investigate that. That seems logical. > In the meantime, can you recompile your kernel and set > CONFIG_ARCH_KIRKWOOD_DT=n ? I can confirm that v3.13-rc8 with CONFIG_ARCH_KIRKWOOD_DT=n works. Thanks, Ian. -- 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/1389777972.12434.115.ca...@kazak.uk.xensource.com
Bug#735428: linux-image-3.12-1-amd64: mei_me reset: connect/disconnect timeout in loop
Package: src:linux Version: 3.12.6-2 Severity: normal Dear Maintainer, since some version of kernel I need to remove mei_me module. This module is loaded at boot time and spam the dmesg with mei_me :00:03.0: reset: connect/disconnect timeout. mei_me :00:03.0: unexpected reset: dev_state = RESETTING This happen every 5 seconds. I thinks this module should be patched to abort if there is a failure after x retries. Regards, Matthieu -- Package-specific info: ** Version: Linux version 3.12-1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.12-1-amd64 root=UUID=5f80d55a-8b6a-42c1-a9ab-0979e1a875f8 ro quiet ** Not tainted ** Kernel log: [8.608411] [drm] Connector 0: [8.608413] [drm] SVIDEO-1 [8.608414] [drm] Encoders: [8.608416] [drm] TV1: INTERNAL_KLDSCP_DAC2 [8.608417] [drm] Connector 1: [8.608419] [drm] DVI-I-1 [8.608420] [drm] HPD2 [8.608423] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [8.608424] [drm] Encoders: [8.608426] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [8.608427] [drm] DFP1: INTERNAL_UNIPHY [8.608429] [drm] Connector 2: [8.608430] [drm] DVI-I-2 [8.608432] [drm] HPD1 [8.608434] [drm] DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c [8.608436] [drm] Encoders: [8.608437] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [8.608439] [drm] DFP2: INTERNAL_UNIPHY2 [8.608465] [drm] Internal thermal controller with fan control [8.608507] [drm] radeon: power management initialized [8.683935] [drm] fb mappable at 0xE045E000 [8.683937] [drm] vram apper at 0xE000 [8.683939] [drm] size 8294400 [8.683940] [drm] fb depth is 24 [8.683942] [drm]pitch is 7680 [8.684016] fbcon: radeondrmfb (fb0) is primary device [8.921836] Console: switching to colour frame buffer device 160x64 [8.926831] radeon :01:00.0: fb0: radeondrmfb frame buffer device [8.926834] radeon :01:00.0: registered panic notifier [8.926856] [drm] Initialized radeon 2.34.0 20080528 for :01:00.0 on minor 0 [9.579369] Adding 979960k swap on /dev/sdc3. Priority:-1 extents:1 across:979960k [9.626517] EXT4-fs (sdc2): re-mounted. Opts: (null) [9.909634] EXT4-fs (sdc2): re-mounted. Opts: errors=remount-ro [ 11.620017] mei_me :00:03.0: reset: connect/disconnect timeout. [ 11.620066] mei_me :00:03.0: unexpected reset: dev_state = RESETTING [ 11.989677] fuse init (API version 7.22) [ 12.238471] smsc47b397: found SMSC SCH5317 (base address 0x0480, revision 2) [ 13.377031] EXT4-fs (sdc4): mounting ext3 file system using the ext4 subsystem [ 13.389506] EXT4-fs (sdc4): mounted filesystem with ordered data mode. Opts: (null) [ 13.389786] EXT4-fs (sdb1): mounting ext3 file system using the ext4 subsystem [ 13.432724] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) [ 13.464283] FAT-fs (sdc1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 14.646071] e1000e :00:19.0: irq 42 for MSI/MSI-X [ 14.748045] e1000e :00:19.0: irq 42 for MSI/MSI-X [ 14.748192] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 17.413479] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 17.413614] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 17.632015] mei_me :00:03.0: reset: connect/disconnect timeout. [ 17.632063] mei_me :00:03.0: unexpected reset: dev_state = RESETTING [ 19.105558] RPC: Registered named UNIX socket transport module. [ 19.105562] RPC: Registered udp transport module. [ 19.105564] RPC: Registered tcp transport module. [ 19.105565] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 19.158534] FS-Cache: Loaded [ 19.243684] FS-Cache: Netfs 'nfs' registered for caching [ 19.348947] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 19.509027] Key type dns_resolver registered [ 19.577953] NFS: Registering the id_resolver key type [ 19.577970] Key type id_resolver registered [ 19.577972] Key type id_legacy registered [ 23.644015] mei_me :00:03.0: reset: connect/disconnect timeout. [ 23.644064] mei_me :00:03.0: unexpected reset: dev_state = RESETTING [ 29.656014] mei_me :00:03.0: reset: connect/disconnect timeout. [ 29.656060] mei_me :00:03.0: unexpected reset: dev_state = RESETTING [ 34.588012] RPC: AUTH_GSS upcall timed out. [ 34.588012] Please check user daemon is running. [ 35.668039] mei_me :00:03.0: reset: connect/disconnect timeout. [ 35.668095] mei_me :00:03.0: unexpected reset: dev_state = RESETTING [ 38.067868] xfs[2122]: segfault at 0 ip (null) sp fff2b77c error 14 in xfs[8047000+1b000] [ 38.964747] lp0: using parport0 (interrupt-driven). [ 38.970376] ppdev: user-space p
Kernel Images for Xenomai
Dear people, there's a project Xenomai [1] that patching the kernel source and providing a library transform a non-realtime system as GNU/Linux into a realtime (hard) system. In debian, we have packaged that [2]. The user, to get the realtime must patch the kernel, configure it build it. There are several guides to do that, for instance [3]. However, configure a Xenomai system it's not easy, because there's a lot of issues that the "normal" user unknown, or are too specific for a developer that need a realtime program. One of the Xenomai developers (Gilles Chanteperdrix) provided some linux images, and other people (myself for example) too. However, in the xenomai list [4], commented about the packages I asked: > Really, it's possible to provide a Xenomai patched kernel for the 95% of the > users/hardware? and the Gilles answer was interesting: > Yes. Starting with the I-pipe core patches, definitely. And if not, I > think this is something we should work on. Because in the long run, if > users installed pre-packaged kernels and did not have to follow the > traditional trial-and-error process of configuring kernels for xenomai, > we would have less questions on this subject on the mailing list. So, what about to create a linux-image package, with a kernel packaged with xenomai? I ask it to the debian kernel maintainers with the lack of knowledge that what it implies, because for example: - xenomai doesn't work in all architectures than debian. - it has patches for previous versions of the linux provided by debian. - who maintain it? However, I think that we can have interested people to work on that, and could be affordable. Thanks in advance, Best regards, Leopold [1] http://www.xenomai.org [2] http://packages.debian.org/source/sid/xenomai [3] http://www.xenomai.org/index.php/Building_Debian_packages [4] http://www.xenomai.org/pipermail/xenomai/2013-December/029706.html -- -- Linux User 152692 Catalonia signature.asc Description: This is a digitally signed message part.
Re: Kernel Images for Xenomai
Hi, thanks for interest in working on this! On 01/15/2014 12:25 PM, Leopold Palomo-Avellaneda wrote: > I ask it to the debian kernel maintainers with the lack of > knowledge that what it implies, because for example: > > - xenomai doesn't work in all architectures than debian. - it has > patches for previous versions of the linux provided by debian. - > who maintain it? > > However, I think that we can have interested people to work on > that, and could be affordable. One of the biggest obstacles is the release schedules of Debian and Xenomai projects, and I can't expect either of them to follow the other. This implies that Debian typically includes an outdated version of Xenomai in its stable version even though I include the respective latest Xenomai release always immediately into Debian unstable. In addition, kernels supported by official Xenomai patches also typically differ from the ones that Debian ships. Since Debian synchronizes quite well now with kernel.org stable branches, there is at least a good chance to synchronize in this second regard. Roland -- 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/52d67a90.6050...@antcom.de
Re: Kernel Images for Xenomai
On 01/15/2014 01:09 PM, Roland Stigge wrote: Hi, thanks for interest in working on this! On 01/15/2014 12:25 PM, Leopold Palomo-Avellaneda wrote: I ask it to the debian kernel maintainers with the lack of knowledge that what it implies, because for example: - xenomai doesn't work in all architectures than debian. - it has patches for previous versions of the linux provided by debian. - who maintain it? However, I think that we can have interested people to work on that, and could be affordable. One of the biggest obstacles is the release schedules of Debian and Xenomai projects, and I can't expect either of them to follow the other. This implies that Debian typically includes an outdated version of Xenomai in its stable version even though I include the respective latest Xenomai release always immediately into Debian unstable. All xenomai releases in a same branch (2.6.1, 2.6.2, 2.6.3, etc...) are ABI compatible, it means that Xenomai can be upgraded without even recompiling applications using it. Would not it make sense then, to package these releases for Debian stable? Using debian backports for instance? Or debian "volatile", if it still exists? In addition, kernels supported by official Xenomai patches also typically differ from the ones that Debian ships. Since Debian synchronizes quite well now with kernel.org stable branches, there is at least a good chance to synchronize in this second regard. Since Leopold is talking about generating patched linux images, does it really matter if they do not use the same versions as the ones used by Debian? -- Gilles. -- 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/52d67c38.5080...@xenomai.org
Re: Kernel Images for Xenomai
On 01/15/2014 01:16 PM, Gilles Chanteperdrix wrote: >> In addition, kernels supported by official Xenomai patches also >> typically differ from the ones that Debian ships. >> >> Since Debian synchronizes quite well now with kernel.org stable >> branches, there is at least a good chance to synchronize in this >> second regard. > > Since Leopold is talking about generating patched linux images, does it > really matter if they do not use the same versions as the ones used by > Debian? Yes, if it's included in Debian stable, we would need to trust someone who steps up to support the respective package (i.e. its over time aging version) for security updates for years. When it's "only" in backports, there is no such hard restriction. Roland -- 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/52d68347.6000...@antcom.de
Bug#690009: "Invalid iomem size. You may experience problems." I do, experience problems.
I see this on a Dell Latitude E6530. $ uname -a Linux ls28101 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux The SD host controller is from O2 Micro, with ID 1217:8221. -- Mark The University of Dundee is a registered Scottish Charity, No: SC015096 -- 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/52d683e4.2040...@dundee.ac.uk
Bug#704242: Driver for PL-2303 HX not working
On Tue, Jan 14, 2014 at 12:01:30AM +0100, Karsten Malcher wrote: > Hello together, > > i will close this bug at Debian now. > > After the last update this error seems to disappear in Debian stable. > http://ftp.debian.org/debian/dists/wheezy/ChangeLog > USB: pl2303: fix device initialisation at open That's good to hear. > The source for this patch can be found here: > http://www.spinics.net/lists/stable/msg30311.html This is not directly related to commit you refer to above (it fixes a different problem). > It's possible that this will not fix the bug under all circumstances > depending on the application. > > Summary: == > > I did need some time to realize that this bug will occur only with > PL2303HX chips that are China clones. In fact this type of chips run > out of production at Profilic. > http://www.prolific.com.tw/US/ShowProduct.aspx?pcid=41&showlevel=0017-0037-0041 > Only the PL2303HXD can be buyed as original, so any new PL2303HX is a > China clone. > > I have been contacted by Frank Schäfer and so we tested some of his > driver improvements in combination with newer kernels. Up to now this > could not be backported to kernel 3.2.x, but i could test a kernel > 3.12.6 on Debian wheezy and the PL2303HX is running fine. > > There are really much products with this clone chips out there, so > some further improvements of the driver would be really helpful. I > will make further tests together with Frank and hope that this > improvements will find a place into the next kernel versions starting > with Debian jessie and 3.12.6 The pl2303 has been cleaned up quite a bit lately (will show up in v3.14), so it should be even easier to add support for further device types with all their quirks. Patches are most welcome. Thanks, Johan -- 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/20140115130556.GF11681@localhost
Re: Kernel Images for Xenomai
On Wed, 2014-01-15 at 12:25 +0100, Leopold Palomo-Avellaneda wrote: > Dear people, > > > there's a project Xenomai [1] that patching the kernel source and providing a > library transform a non-realtime system as GNU/Linux into a realtime (hard) > system. > > In debian, we have packaged that [2]. The user, to get the realtime must > patch > the kernel, configure it build it. There are several guides to do that, for > instance [3]. However, configure a Xenomai system it's not easy, because > there's a lot of issues that the "normal" user unknown, or are too specific > for a developer that need a realtime program. > > One of the Xenomai developers (Gilles Chanteperdrix) provided some linux > images, and other people (myself for example) too. However, in the xenomai > list [4], commented about the packages I asked: > > > Really, it's possible to provide a Xenomai patched kernel for the 95% of the > > users/hardware? > > and the Gilles answer was interesting: > > > Yes. Starting with the I-pipe core patches, definitely. And if not, I > > think this is something we should work on. Because in the long run, if > > users installed pre-packaged kernels and did not have to follow the > > traditional trial-and-error process of configuring kernels for xenomai, > > we would have less questions on this subject on the mailing list. > > So, what about to create a linux-image package, with a kernel packaged with > xenomai? All kernel featuresets should be temporary, with the project aiming to get their changes merged upstream. http://www.xenomai.org/index.php/Xenomai:Roadmap doesn't say anything about doing that, and if that isn't planned then I will reject this proposal. We already provide realtime kernel images using the PREEMPT_RT patch series. Two types of realtime kernel would be an extravagance. But as Xenomai apparently runs on top of PREEMPT_RT now, that might not be a problem. > I ask it to the debian kernel maintainers with the lack of knowledge that > what > it implies, because for example: > > - xenomai doesn't work in all architectures than debian. That doesn't matter. > - it has patches for previous versions of the linux provided by debian. There is only one version of Linux in each suite, and this is not likely to change. So if Xenomai doesn't keep up with upstream development then it would have to be disabled at times. (We currently do this with the 'rt' featureset on odd-numbered Linux versions.) > - who maintain it? > > However, I think that we can have interested people to work on that, and > could > be affordable. There needs to be a nominated maintainer for each featureset. (In practice I've been looking after the 'rt' featureset, but I'm not offering to do that for anything else.) The maintainer will need to be ready to resolve patch (and semantic) conflicts whenever the Linux upstream version is updated, including stable updates. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
Re: Kernel Images for Xenomai
A Dimecres, 15 de gener de 2014, Roland Stigge va escriure: > On 01/15/2014 01:16 PM, Gilles Chanteperdrix wrote: > >> In addition, kernels supported by official Xenomai patches also > >> typically differ from the ones that Debian ships. > >> > >> Since Debian synchronizes quite well now with kernel.org stable > >> branches, there is at least a good chance to synchronize in this > >> second regard. > > > > Since Leopold is talking about generating patched linux images, does it > > really matter if they do not use the same versions as the ones used by > > Debian? > > Yes, if it's included in Debian stable, we would need to trust someone > who steps up to support the respective package (i.e. its over time aging > version) for security updates for years. > > When it's "only" in backports, there is no such hard restriction. > I like the option of backports. Also, an outdated version in stable could be a good option for an starting place for a new user. However, I would like to see the kernel maintainers opinion. Leopold PS. Really, if we could have it, we can then have a bunch of realtime software packages, so we could have some debianrt ecosystem -- -- Linux User 152692 Catalonia signature.asc Description: This is a digitally signed message part.
Re: Kernel Images for Xenomai
On Wed, 2014-01-15 at 15:07 +0100, Leopold Palomo-Avellaneda wrote: > A Dimecres, 15 de gener de 2014, Roland Stigge va escriure: > > On 01/15/2014 01:16 PM, Gilles Chanteperdrix wrote: > > >> In addition, kernels supported by official Xenomai patches also > > >> typically differ from the ones that Debian ships. > > >> > > >> Since Debian synchronizes quite well now with kernel.org stable > > >> branches, there is at least a good chance to synchronize in this > > >> second regard. > > > > > > Since Leopold is talking about generating patched linux images, does it > > > really matter if they do not use the same versions as the ones used by > > > Debian? > > > > Yes, if it's included in Debian stable, we would need to trust someone > > who steps up to support the respective package (i.e. its over time aging > > version) for security updates for years. > > > > When it's "only" in backports, there is no such hard restriction. > > > > I like the option of backports. [...] All packages in backports must first be present in testing. Which means they must first be intended to be included in (the next) stable. So, there really has to be security support in stable, based on a single stable upstream version. (Based on current release schedules, the current upstream version of Linux at the time of jessie's freeze (5th November) will be 3.17 so I would expect us to use either 3.16 or 3.17. Ideally this would also be the base version for Greg K-H's next longterm branch. I have no intention of maintaining two longterm branches myself.) Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
Bug#735458: firmware-free: Drop reference to obsolete linux-image virtual package
Source: firmware-free Version: 3.2 Severity: normal Usertags: obsolete-linux-image Hello, one (or more) binary package(s) generated by the firmware-free source package still mentions the âlinux-imageâ virtual package in Recommends or Suggests. That virtual package is obsolete since the latest linux-image-* packages no longer provide this virtual package. See https://lists.debian.org/debian-devel/2013/09/msg00539.html for the rationale and some details. The presence of this virtual package in Recommends has the rather annoying side effect that when you try to install the package with APT, and that you have say wheezy and jessie repositories, APT will install the wheezy kernel that still provides linux-image and this even though you already have a jessie kernel installed... Please get rid of those linux-image dependencies. Cheers, -- Raphaël Hertzog â Debian Developer Discover the Debian Administrator's Handbook: â http://debian-handbook.info/get/ -- 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/20140115153734.6938c5a0...@soleymieux.ouaza.com
Reassign to proper source package
reassign 735462 src:firmware-nonfree 0.40 thanks I just filed #735462 to ask for the removal of the reference to the obsolete linux-image package but I typoed the source package name. Reassigning now. -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140115154959.ga2...@x230-buxy.home.ouaza.com
Processed: Reassign to proper source package
Processing commands for cont...@bugs.debian.org: > reassign 735462 src:firmware-nonfree 0.40 Bug #735462 [src:firmware-non-free] firmware-non-free: Drop reference to obsolete linux-image virtual package Warning: Unknown package 'src:firmware-non-free' Bug reassigned from package 'src:firmware-non-free' to 'src:firmware-nonfree'. No longer marked as found in versions firmware-non-free/0.40. Ignoring request to alter fixed versions of bug #735462 to the same values previously set Bug #735462 [src:firmware-nonfree] firmware-non-free: Drop reference to obsolete linux-image virtual package Marked as found in versions firmware-nonfree/0.40. > thanks Stopping processing here. Please contact me if you need assistance. -- 735462: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735462 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.138980100229312.transcr...@bugs.debian.org
Re: Kernel Images for Xenomai
Hi, first of all please CC to me because I'm not in the kernel list. I saw the message in the web interface. > > > > So, what about to create a linux-image package, with a kernel packaged > > with xenomai? > > All kernel featuresets should be temporary, with the project aiming to > get their changes merged upstream. > http://www.xenomai.org/index.php/Xenomai:Roadmap doesn't say anything > about doing that, and if that isn't planned then I will reject this > proposal. well, Gilles could answer better than me, but Xenomai works with the adeos patch and the linux kernel is just another task. I don't know if it could be mixed, they are two different things. One is an kernel with the scheduler modified to try to do realtime features and another is an subkernel on Linux kernel run as a task. Another thing is if they will converge with the PREEMP_RT patches from Ingo Molnar and Co. > We already provide realtime kernel images using the PREEMPT_RT patch > series. Two types of realtime kernel would be an extravagance. One is a "Soft" realtime and another "Hard" realtime. Although in my area (robotics), the 95% of the applications could be perfect with the PREEMPT_RT version, there's another areas that could be benefit this option, so IMHO it's not an extravagance. I can say more, if Debian could have a group of packages that work on a hard realtime subset, specially on ARM, it would be a good plus to the project; better, we are towards the "world domination" ;-) > But as > Xenomai apparently runs on top of PREEMPT_RT now, that might not be a > problem. I don't think so. I don't apply the PREEMPT_RT patch to use Xenomai. Gilles, I'm right? > > I ask it to the debian kernel maintainers with the lack of knowledge that > > what it implies, because for example: > > > > - xenomai doesn't work in all architectures than debian. > > That doesn't matter. Ok > > - it has patches for previous versions of the linux provided by debian. > > There is only one version of Linux in each suite, and this is not likely > to change. So if Xenomai doesn't keep up with upstream development then > it would have to be disabled at times. (We currently do this with the > 'rt' featureset on odd-numbered Linux versions.) Ok, Gilles, would be possible to be sync and have a Adeos patch for the stable version included in debian? > > - who maintain it? > > > > However, I think that we can have interested people to work on that, and > > could be affordable. > > There needs to be a nominated maintainer for each featureset. (In > practice I've been looking after the 'rt' featureset, but I'm not > offering to do that for anything else.) The maintainer will need to be > ready to resolve patch (and semantic) conflicts whenever the Linux > upstream version is updated, including stable updates. Well, Roland have done a good job with the xenomai package, and AFAIK some xenomai upstream and debian user, and I can help for this of course. Regards, Leopold -- -- Linux User 152692 Catalonia signature.asc Description: This is a digitally signed message part.
Bug#735496: initramfs-tools fails because of missing keyutils package
Package: initramfs-tools Version: 0.115~bpo70+1 Severity: normal I am using wheezy mostyle stable and also backports packages (such as initramfs-tools) I have multiple volumes encrypted using dm_crypt (3 LVM Physical Volumes) using the same passphrase I do not want to type the passphrase three times hence I am using the following option in /etc/crypttab "luks,keyscript=decrypt_keyctl" The problem is update-initramfs fails because /bin/keyctl is required but it is not installed. It works after I installed keyutils but I had to debug the script to figure out what had to be installed. A package dependency should make sure this program is already installed to avoid this problem. # cat /etc/crypttab luks-0d020ecb-9fae-40fb-9ddf-8a75c8830d9c UUID=0d020ecb-9fae-40fb-9ddf- 8a75c8830d9c none luks,keyscript=decrypt_keyctl luks-182a31c7-38da-4c7f-9bf6-3568c0dbf1d4 UUID=182a31c7-38da-4c7f- 9bf6-3568c0dbf1d4 none luks,keyscript=decrypt_keyctl luks-d1c60f39-a178-46f9-824d-6353b97158c3 UUID=d1c60f39-a178-46f9-824d- 6353b97158c3 none luks,keyscript=decrypt_keyctl # cat /etc/debian_version 7.3 The main "update-initramfs" command fails: # update-initramfs -u -k all update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1. update-initramfs: failed for /boot/initrd.img-3.2.0-4-amd64 with 1. The internal commands which fails: # mkinitramfs -o /boot/initrd.img-3.2.0-4-amd64.new 3.2.0-4-amd64 E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1. # bash -x /usr/share/initramfs-tools/hooks/cryptkeyctl + set -e + PREREQ=cryptroot + case $1 in + . /usr/share/initramfs-tools/hook-functions + '[' '!' -x /lib/cryptsetup/scripts/decrypt_keyctl ']' + copy_exec /bin/keyctl + local src target x nonoptlib + local libname dirname + src=/bin/keyctl + target=/bin/keyctl + '[' -f /bin/keyctl ']' + return 1 The missing program is /bin/keyctl: # ls -lh /bin/keyctl ls: cannot access /bin/keyctl: No such file or directory The solution is to install the missing package: # apt-get install keyutils Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: keyutils 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 36.2 kB of archives. After this operation, 86.0 kB of additional disk space will be used. Get:1 http://ftp.uk.debian.org/debian/ wheezy/main keyutils amd64 1.5.5-3 [36.2 kB] Fetched 36.2 kB in 0s (125 kB/s) Selecting previously unselected package keyutils. (Reading database ... 125426 files and directories currently installed.) Unpacking keyutils (from .../keyutils_1.5.5-3_amd64.deb) ... Processing triggers for man-db ... Setting up keyutils (1.5.5-3) ... Finally it works: # update-initramfs -u -k all update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 12M Jan 15 19:18 /boot/initrd.img-3.2.0-4-amd64 -rw-r--r-- 1 root root 12M Jan 12 17:58 /boot/initrd.img-3.2.0-4-amd64-20140112-1800 -rw-r--r-- 1 root root 12M Jan 15 19:23 /boot/initrd.img-3.2.0-4-amd64-20140115-1918 -- /proc/cmdline root=/dev/vgmain/sys_debian07 ro quiet -- /proc/filesystems btrfs ext4 xfs ext3 -- lsmod Module Size Used by dm_mirror 17707 1 dm_region_hash 13502 1 dm_mirror dm_log 13528 3 dm_region_hash,dm_mirror ip6table_filter12540 0 ebtable_nat12580 0 ebtables 26235 1 ebtable_nat parport_pc 22364 0 ppdev 12763 0 lp 17149 0 parport31858 3 lp,ppdev,parport_pc bnep 17567 2 rfcomm 33700 10 binfmt_misc12957 1 act_police 12654 1 cls_basic 12966 1 cls_flow 17351 0 cls_fw 12965 4 cls_u3213071 0 sch_tbf12964 0 sch_prio 13163 0 sch_htb17923 1 sch_hfsc 22230 0 sch_ingress12744 1 sch_sfq13172 4 xt_statistic 12519 0 xt_CT 12507 0 xt_time12459 0 xt_connlimit 12622 0 xt_realm 12423 0 xt_addrtype12557 4 iptable_raw12524 0 xt_comment 12427 9 xt_recent 13188 0 xt_policy 12506 0 ipt_ULOG 16833 0 ipt_REJECT 12502 4 ipt_REDIRECT 12471 0 ipt_NETMAP 12465 0 ipt_MASQUERADE 12594 3 ipt_ECN12456 0 ipt_ecn12456 0 ipt_CLUSTERIP 13045 0 ipt_ah 12453 0 xt_set 12989 0 ip_set 26649 1 xt_set nf_nat_tftp1
Re: Kernel Images for Xenomai
On 01/15/2014 05:15 PM, Leopold Palomo-Avellaneda wrote: > Hi, > > first of all please CC to me because I'm not in the kernel list. I saw the > message in the web interface. > >>> >>> So, what about to create a linux-image package, with a kernel packaged >>> with xenomai? >> >> All kernel featuresets should be temporary, with the project aiming to >> get their changes merged upstream. >> http://www.xenomai.org/index.php/Xenomai:Roadmap doesn't say anything >> about doing that, and if that isn't planned then I will reject this >> proposal. > > well, Gilles could answer better than me, but Xenomai works with the adeos > patch and the linux kernel is just another task. I don't know if it could be > mixed, they are two different things. One is an kernel with the scheduler > modified to try to do realtime features and another is an subkernel on Linux > kernel run as a task. That settles it then, it has been made very clear a long, long time ago that the Adeos patch would never be merged into mainline. > Another thing is if they will converge with the PREEMP_RT patches from Ingo > Molnar and Co. > >> We already provide realtime kernel images using the PREEMPT_RT patch >> series. Two types of realtime kernel would be an extravagance. > > One is a "Soft" realtime and another "Hard" realtime. Although in my area > (robotics), the 95% of the applications could be perfect with the PREEMPT_RT > version, there's another areas that could be benefit this option, so IMHO > it's > not an extravagance. I can say more, if Debian could have a group of packages > that work on a hard realtime subset, specially on ARM, it would be a good > plus > to the project; better, we are towards the "world domination" ;-) No, PREEMPT_RT is hard real-time as well, the two approaches are simply different and both have their strengthes and weaknesses. You will find a comparison between the various approaches for getting real-time services with Linux here: http://www2.hs-augsburg.de/informatik/vorlesungen/echtzeit/script/system/linux_rt01.html The Adeos/Xenomai approach corresponds more or less to section 6. > >> But as >> Xenomai apparently runs on top of PREEMPT_RT now, that might not be a >> problem. > > I don't think so. I don't apply the PREEMPT_RT patch to use Xenomai. Gilles, > I'm right? The idea with the next (currently unreleased) branch of Xenomai is to offer users the choice of the kernel they want to use. The aim of Xenomai is not to provide real-time services using a particular approach or another, but to help porting application from proprietary RTOSes, such as vxworks, psos, etc... to a real-time Linux-based system. The particular approach used to get real-time services is secondary. >>> - it has patches for previous versions of the linux provided by debian. >> >> There is only one version of Linux in each suite, and this is not likely >> to change. So if Xenomai doesn't keep up with upstream development then >> it would have to be disabled at times. (We currently do this with the >> 'rt' featureset on odd-numbered Linux versions.) > > Ok, Gilles, would be possible to be sync and have a Adeos patch for the > stable > version included in debian? AFAIK the version of Linux in debian stable is 3.2, and we already have an Adeos patch for 3.2. Or are you talking about the Linux version available for stable in debian backports? >> There needs to be a nominated maintainer for each featureset. (In >> practice I've been looking after the 'rt' featureset, but I'm not >> offering to do that for anything else.) The maintainer will need to be >> ready to resolve patch (and semantic) conflicts whenever the Linux >> upstream version is updated, including stable updates. > > Well, Roland have done a good job with the xenomai package, and AFAIK some > xenomai upstream and debian user, and I can help for this of course. No question here that the one who would maintain the xenomai-patched linux image would have to be familiar with xenomai. -- Gilles. -- 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/52d6e6ce.9030...@xenomai.org
Bug#735172: v3.12 regression from "ARM: kirkwood: convert to DT irqchip and clocksource" on non-DT kirkwood platforms
On 01/15/2014 10:26 AM, Ian Campbell wrote:
On Wed, 2014-01-15 at 10:15 +0100, Sebastian Hesselbarth wrote:
On 01/15/14 09:40, Ian Campbell wrote:
The bootlogs are below or in the bug. It stops after "Console: colour
dummy device 80x30", I think next would normally be the
BogoMIPS/calibrate_delay output.
That would indicate the timer (clocksource) or irq (irqchip) is not
running correctly. Again, that could be non-DT and DT fighting for it.
I'll investigate that.
That seems logical.
In the meantime, can you recompile your kernel and set
CONFIG_ARCH_KIRKWOOD_DT=n ?
I can confirm that v3.13-rc8 with CONFIG_ARCH_KIRKWOOD_DT=n works.
Ian,
please try the following two patches on top of v3.13-rc8 and report
back, if it solves the regression.
I have tested this on a revived non-DT Kirkwood Dockstar with and
without DT support enabled. I also compile tested it for Orion5x
and Dove.
While I will not send any patches for non-DT mach-dove boards as
none of them is really used anymore, Gregory is on Cc for hopefully
testing orion5x.
For possible -stable patches, I know it is quite a huge patch but
I didn't dare to touch arch/arm/kernel/foo for this kind of regression.
Sebastian
(I hope the fscking Thunderbird inlines both patches correctly)
>From 551749f716c6a362ccbbfde74ef47c2cbb372805 Mon Sep 17 00:00:00 2001
From: Sebastian Hesselbarth
Date: Wed, 15 Jan 2014 20:00:21 +0100
Subject: [PATCH 1/2] ARM: orion: provide C-style interrupt handler for
MULTI_IRQ_HANDLER
Compiling with both non-DT and DT support enabled, will break ASM irq
handler used by non-DT boards. Therefore, we provide a C-style irq
handler even for non-DT boards, if MULTI_IRQ_HANDLER is set.
Signed-off-by: Sebastian Hesselbarth
---
arch/arm/plat-orion/include/plat/irq.h | 1 +
arch/arm/plat-orion/irq.c | 43 ++
2 files changed, 44 insertions(+)
diff --git a/arch/arm/plat-orion/include/plat/irq.h b/arch/arm/plat-orion/include/plat/irq.h
index 50547e417936..75a38b577460 100644
--- a/arch/arm/plat-orion/include/plat/irq.h
+++ b/arch/arm/plat-orion/include/plat/irq.h
@@ -11,6 +11,7 @@
#ifndef __PLAT_IRQ_H
#define __PLAT_IRQ_H
+void orion_legacy_handle_irq(struct pt_regs *regs);
void orion_irq_init(unsigned int irq_start, void __iomem *maskaddr);
void __init orion_dt_init_irq(void);
#endif
diff --git a/arch/arm/plat-orion/irq.c b/arch/arm/plat-orion/irq.c
index c492e1b3dfdb..82dd811b05c4 100644
--- a/arch/arm/plat-orion/irq.c
+++ b/arch/arm/plat-orion/irq.c
@@ -15,8 +15,51 @@
#include
#include
#include
+#include
#include
#include
+#include
+
+#ifdef CONFIG_MULTI_IRQ_HANDLER
+/*
+ * Compiling with both non-DT and DT support enabled, will
+ * break asm irq handler used by non-DT boards. Therefore,
+ * we provide a C-style irq handler even for non-DT boards,
+ * if MULTI_IRQ_HANDLER is set.
+ */
+
+#ifdef CONFIG_ARCH_ORION5X
+/* Orion5x only has one irq cause and different macro names */
+# define IRQ_VIRT_BASE MAIN_IRQ_CAUSE
+# define IRQ_CAUSE_LOW_OFF 0x00
+# define IRQ_MASK_LOW_OFF 0x04
+#endif
+
+static void __iomem *orion_irq_base = IRQ_VIRT_BASE;
+
+asmlinkage void
+__exception_irq_entry orion_legacy_handle_irq(struct pt_regs *regs)
+{
+ u32 stat;
+
+ stat = readl_relaxed(orion_irq_base + IRQ_CAUSE_LOW_OFF);
+ stat &= readl_relaxed(orion_irq_base + IRQ_MASK_LOW_OFF);
+ if (stat) {
+ int hwirq = __fls(stat);
+ handle_IRQ(hwirq, regs);
+ return;
+ }
+#ifndef CONFIG_ARCH_ORION5X
+ stat = readl_relaxed(orion_irq_base + IRQ_CAUSE_HIGH_OFF);
+ stat &= readl_relaxed(orion_irq_base + IRQ_MASK_HIGH_OFF);
+ if (stat) {
+ int hwirq = 32 + __fls(stat);
+ handle_IRQ(hwirq, regs);
+ return;
+ }
+#endif
+}
+#endif
void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr)
{
--
1.8.5.2
>From 07c46c0d285d2c9d4f0ec4406a80a18f2f65fe0c Mon Sep 17 00:00:00 2001
From: Sebastian Hesselbarth
Date: Wed, 15 Jan 2014 20:34:08 +0100
Subject: [PATCH 2/2] ARM: kirkwood: set C-style handle_irq if
MULTI_IRQ_HANDLER is set
Compiling with both non-DT and DT support enabled, will break ASM
irq handler used by non-DT boards. This fixes a regression for
those kernels by installing a corresponding C-style handle_irq
callback if MULTI_IRQ_HANDLER is set.
Signed-off-by: Sebastian Hesselbarth
---
arch/arm/mach-kirkwood/d2net_v2-setup.c | 4
arch/arm/mach-kirkwood/netxbig_v2-setup.c| 7 +++
arch/arm/mach-kirkwood/openrd-setup.c| 10 ++
arch/arm/mach-kirkwood/rd88f6192-nas-setup.c | 4
arch/arm/mach-kirkwood/rd88f6281-setup.c | 4
arch/arm/mach-kirkwood/t5325-setup.c | 4
arch/arm/mach-kirkwood/ts219-setup.c | 4
arch/arm/mach-kirkwood/ts41x-setup.c | 4
8 files changed, 41 insertions(+)
diff --git a/arch/arm/mach-kirkwood/d2net_v2-setup.c b/arch/arm/mach-kirkwood/d2net_v2-setup.c
index 453418063c1e..7b475af4f904 100644
--- a/arch/arm/mach-kirkwood/d2net_v2-setup.c
+++ b/arc
Bug#735172: v3.12 regression from "ARM: kirkwood: convert to DT irqchip and clocksource" on non-DT kirkwood platforms
On Wed, 2014-01-15 at 20:54 +0100, Sebastian Hesselbarth wrote: > please try the following two patches on top of v3.13-rc8 and report > back, if it solves the regression. Yes, it works fine, thanks! Tested-by: Ian Campbell signature.asc Description: This is a digitally signed message part
Bug#735496: initramfs-tools fails because of missing keyutils package
reassign 735496 cryptsetup stop On Wed, Jan 15, 2014 at 07:45:06PM +, fdupoux wrote: > Package: initramfs-tools > Version: 0.115~bpo70+1 > Severity: normal > > I am using wheezy mostyle stable and also backports packages (such as > initramfs-tools) > I have multiple volumes encrypted using dm_crypt (3 LVM Physical Volumes) > using > the same passphrase > I do not want to type the passphrase three times hence I am using the > following > option in /etc/crypttab > "luks,keyscript=decrypt_keyctl" > > The problem is update-initramfs fails because /bin/keyctl is required but it > is > not installed. > It works after I installed keyutils but I had to debug the script to figure > out > what had to be installed. > A package dependency should make sure this program is already installed to > avoid this problem. > > # cat /etc/crypttab > luks-0d020ecb-9fae-40fb-9ddf-8a75c8830d9c UUID=0d020ecb-9fae-40fb-9ddf- > 8a75c8830d9c none luks,keyscript=decrypt_keyctl > luks-182a31c7-38da-4c7f-9bf6-3568c0dbf1d4 UUID=182a31c7-38da-4c7f- > 9bf6-3568c0dbf1d4 none luks,keyscript=decrypt_keyctl > luks-d1c60f39-a178-46f9-824d-6353b97158c3 UUID=d1c60f39-a178-46f9-824d- > 6353b97158c3 none luks,keyscript=decrypt_keyctl > > # cat /etc/debian_version > 7.3 > > The main "update-initramfs" command fails: > > # update-initramfs -u -k all > update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 > E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1. > update-initramfs: failed for /boot/initrd.img-3.2.0-4-amd64 with 1. > > The internal commands which fails: > > # mkinitramfs -o /boot/initrd.img-3.2.0-4-amd64.new 3.2.0-4-amd64 > E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1. dpkg -S /usr/share/initramfs-tools/hooks/cryptkeyctl would tell, which package that files belongs too, hence reassigned. > # bash -x /usr/share/initramfs-tools/hooks/cryptkeyctl > + set -e > + PREREQ=cryptroot > + case $1 in > + . /usr/share/initramfs-tools/hook-functions > + '[' '!' -x /lib/cryptsetup/scripts/decrypt_keyctl ']' > + copy_exec /bin/keyctl > + local src target x nonoptlib > + local libname dirname > + src=/bin/keyctl > + target=/bin/keyctl > + '[' -f /bin/keyctl ']' > + return 1 > > The missing program is /bin/keyctl: > > # ls -lh /bin/keyctl > ls: cannot access /bin/keyctl: No such file or directory > > The solution is to install the missing package: > > # apt-get install keyutils > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following NEW packages will be installed: > keyutils > 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. > Need to get 36.2 kB of archives. > After this operation, 86.0 kB of additional disk space will be used. > Get:1 http://ftp.uk.debian.org/debian/ wheezy/main keyutils amd64 1.5.5-3 > [36.2 > kB] > Fetched 36.2 kB in 0s (125 kB/s) > Selecting previously unselected package keyutils. > (Reading database ... 125426 files and directories currently installed.) > Unpacking keyutils (from .../keyutils_1.5.5-3_amd64.deb) ... > Processing triggers for man-db ... > Setting up keyutils (1.5.5-3) ... > > Finally it works: thanks. > # update-initramfs -u -k all > update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 -- maks -- 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/20140115205201.ge8...@stro.at
Processed: Re: Bug#735496: initramfs-tools fails because of missing keyutils package
Processing commands for cont...@bugs.debian.org: > reassign 735496 cryptsetup Bug #735496 [initramfs-tools] initramfs-tools fails because of missing keyutils package Bug reassigned from package 'initramfs-tools' to 'cryptsetup'. No longer marked as found in versions initramfs-tools/0.115~bpo70+1. Ignoring request to alter fixed versions of bug #735496 to the same values previously set > stop Stopping processing here. Please contact me if you need assistance. -- 735496: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735496 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13898195682.transcr...@bugs.debian.org
Processed: Re: Bug#735462: firmware-non-free: Drop reference to obsolete linux-image virtual package
Processing control commands: > reassign -1 src:firmware-nonfree Bug #735462 [src:firmware-nonfree] firmware-non-free: Drop reference to obsolete linux-image virtual package Ignoring request to reassign bug #735462 to the same package -- 735462: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735462 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.m735462.13898210103704.transcr...@bugs.debian.org
Bug#735462: firmware-non-free: Drop reference to obsolete linux-image virtual package
Control: reassign -1 src:firmware-nonfree On Mi, 15 ian 14, 16:37:34, hert...@debian.org wrote: > Source: firmware-non-free > Version: 0.40 > Severity: normal > Usertags: obsolete-linux-image > > Hello, > > one (or more) binary package(s) generated by the firmware-non-free > source package still mentions the “linux-image” virtual package > in Recommends or Suggests. That virtual package is obsolete since the > latest linux-image-* packages no longer provide this virtual package. > > See https://lists.debian.org/debian-devel/2013/09/msg00539.html for > the rationale and some details. > > The presence of this virtual package in Recommends has the rather > annoying side effect that when you try to install the package with > APT, and that you have say wheezy and jessie repositories, APT will > install the wheezy kernel that still provides linux-image and this > even though you already have a jessie kernel installed... > > Please get rid of those linux-image dependencies. > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Discover the Debian Administrator's Handbook: > → http://debian-handbook.info/get/ -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Kernel Images for Xenomai
El Dimecres, 15 de gener de 2014, a les 20:51:42, Gilles Chanteperdrix va escriure: > On 01/15/2014 05:15 PM, Leopold Palomo-Avellaneda wrote: > > Hi, > > > > first of all please CC to me because I'm not in the kernel list. I saw the > > message in the web interface. > > > >>> So, what about to create a linux-image package, with a kernel packaged > >>> with xenomai? > >> > >> All kernel featuresets should be temporary, with the project aiming to > >> get their changes merged upstream. > >> http://www.xenomai.org/index.php/Xenomai:Roadmap doesn't say anything > >> about doing that, and if that isn't planned then I will reject this > >> proposal. > > > > well, Gilles could answer better than me, but Xenomai works with the adeos > > patch and the linux kernel is just another task. I don't know if it could > > be mixed, they are two different things. One is an kernel with the > > scheduler modified to try to do realtime features and another is an > > subkernel on Linux kernel run as a task. > > That settles it then, it has been made very clear a long, long time ago that > the Adeos patch would never be merged into mainline. > > > Another thing is if they will converge with the PREEMP_RT patches from > > Ingo > > Molnar and Co. > > > >> We already provide realtime kernel images using the PREEMPT_RT patch > >> series. Two types of realtime kernel would be an extravagance. > > > > One is a "Soft" realtime and another "Hard" realtime. Although in my area > > (robotics), the 95% of the applications could be perfect with the > > PREEMPT_RT version, there's another areas that could be benefit this > > option, so IMHO it's not an extravagance. I can say more, if Debian could > > have a group of packages that work on a hard realtime subset, specially > > on ARM, it would be a good plus to the project; better, we are towards > > the "world domination" ;-) > > No, PREEMPT_RT is hard real-time as well, the two approaches are simply > different and both have their strengthes and weaknesses. You will find > a comparison between the various approaches for getting real-time > services with Linux here: > > http://www2.hs-augsburg.de/informatik/vorlesungen/echtzeit/script/system/lin > ux_rt01.html > > The Adeos/Xenomai approach corresponds more or less to section 6. Ohhh, thanks for the clarification. I was wrong. And the link you sent is incredible how long and clear message. This information should be on the xenomai wiki. > >> But as > >> Xenomai apparently runs on top of PREEMPT_RT now, that might not be a > >> problem. > > > > I don't think so. I don't apply the PREEMPT_RT patch to use Xenomai. > > Gilles, I'm right? > > The idea with the next (currently unreleased) branch of Xenomai is to > offer users the choice of the kernel they want to use. The aim of > Xenomai is not to provide real-time services using a particular > approach or another, but to help porting application from proprietary > RTOSes, such as vxworks, psos, etc... to a real-time Linux-based > system. The particular approach used to get real-time services is > secondary. So, I understand that the libxenomai would be compiled against one or another kernel patch, no? > >>> - it has patches for previous versions of the linux provided by debian. > >> > >> There is only one version of Linux in each suite, and this is not likely > >> to change. So if Xenomai doesn't keep up with upstream development then > >> it would have to be disabled at times. (We currently do this with the > >> 'rt' featureset on odd-numbered Linux versions.) > > > > Ok, Gilles, would be possible to be sync and have a Adeos patch for the > > stable version included in debian? > > AFAIK the version of Linux in debian stable is 3.2, and we already have > an Adeos patch for 3.2. Or are you talking about the Linux version > available for stable in debian backports? Well, we should work on the _next_ stable release. Looking the Ben Hutchings mail: > (Based on current release schedules, the current upstream version of > Linux at the time of jessie's freeze (5th November) will be 3.17 so I > would expect us to use either 3.16 or 3.17. Ideally this would also be > the base version for Greg K-H's next longterm branch. I have no > intention of maintaining two longterm branches myself.) so, the idea should be to have an Adeos patch based on the long term branch. For instance, currently we have in amd64 3.12+55, in unstable, testing and backports. > >> There needs to be a nominated maintainer for each featureset. (In > >> practice I've been looking after the 'rt' featureset, but I'm not > >> offering to do that for anything else.) The maintainer will need to be > >> ready to resolve patch (and semantic) conflicts whenever the Linux > >> upstream version is updated, including stable updates. > > > > Well, Roland have done a good job with the xenomai package, and AFAIK some > > xenomai upstream and debian user, and I can help for this of course. > > No question
Bug#717765: linux-image-3.2.0-4-amd64: panic in ccm crypto module
Good news, I just noticed 3.12 hit wheezy-backports and the changelog includes: crypto: ccm - Fix handling of zero plaintext when computing mac I found the patch on LKML, it's patch description is quite detailed and includes a backtrace that looks very much like the one I reported in this bug (only difference is some Xen bits on the stack), and best of all it looks like Ben Hutchings has backported it to 3.2. On 12/28/2013 06:08 PM, Ben Hutchings wrote: > 3.2.54-rc1 review patch. If anyone has any objections, please let me > know. > > -- > > From: Horia Geanta > > commit 5638cabf3e4883f38dfb246c30980cebf694fbda upstream. > > There are cases when cryptlen can be zero in crypto_ccm_auth(): > -encryptiom: input scatterlist length is zero (no plaintext) > -decryption: input scatterlist contains only the mac > plus the condition of having different source and destination buffers > (or else scatterlist length = max(plaintext_len, ciphertext_len)). > > These are not handled correctly, leading to crashes like: > > root@p4080ds:~/crypto# insmod tcrypt.ko mode=45 > [ cut here ] > kernel BUG at crypto/scatterwalk.c:37! > Oops: Exception in kernel mode, sig: 5 [#1] > SMP NR_CPUS=8 P4080 DS > Modules linked in: tcrypt(+) crc32c xts xcbc vmac pcbc ecb gcm > ghash_generic gf128mul ccm ctr seqiv > CPU: 3 PID: 1082 Comm: cryptomgr_test Not tainted 3.11.0 #14 > task: ee12c5b0 ti: eecd task.ti: eecd > NIP: c0204d98 LR: f9225848 CTR: c0204d80 > REGS: eecd1b70 TRAP: 0700 Not tainted (3.11.0) > MSR: 00029002 CR: 22044022 XER: 2000 > > GPR00: f9225c94 eecd1c20 ee12c5b0 eecd1c28 ee879400 ee879400 ee607464 > GPR08: 0001 0001 006b c0204d80 0002 c0698e20 > GPR16: ee987000 ee895000 fff4 ee879500 0100 eecd1d58 0001 > GPR24: ee879400 0020 ee5b2800 ee607430 0004 ee607460 > NIP [c0204d98] scatterwalk_start+0x18/0x30 > LR [f9225848] get_data_to_compute+0x28/0x2f0 [ccm] > Call Trace: > [eecd1c20] [f9225974] get_data_to_compute+0x154/0x2f0 [ccm] > (unreliable) > [eecd1c70] [f9225c94] crypto_ccm_auth+0x184/0x1d0 [ccm] > [eecd1cb0] [f9225d40] crypto_ccm_encrypt+0x60/0x2d0 [ccm] > [eecd1cf0] [c020d77c] __test_aead+0x3ec/0xe20 > [eecd1e20] [c020f35c] test_aead+0x6c/0xe0 > [eecd1e40] [c020f420] alg_test_aead+0x50/0xd0 > [eecd1e60] [c020e5e4] alg_test+0x114/0x2e0 > [eecd1ee0] [c020bd1c] cryptomgr_test+0x4c/0x60 > [eecd1ef0] [c0047058] kthread+0xa8/0xb0 > [eecd1f40] [c000eb0c] ret_from_kernel_thread+0x5c/0x64 > Instruction dump: > 0f08 81290024 552807fe 0f08 5529003a 4bb4 9083 > 3940 > 3901 8124000c 2f89 7d28579e <0f09> 81240008 91230004 > 4e800020 > ---[ end trace 6d652dfcd1be37bd ]--- > > Cc: Jussi Kivilinna > Signed-off-by: Horia Geanta > Signed-off-by: Herbert Xu > Signed-off-by: Ben Hutchings > --- > crypto/ccm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > --- a/crypto/ccm.c > +++ b/crypto/ccm.c > @@ -271,7 +271,8 @@ static int crypto_ccm_auth(struct aead_r >} > > /* compute plaintext into mac */ > - get_data_to_compute(cipher, pctx, plain, cryptlen); > + if (cryptlen) > +get_data_to_compute(cipher, pctx, plain, cryptlen); > > out: > return err; > It's only been a few hours since I've upgraded to linux-image-3.12-0.bpo.1-amd64 3.12.6-2~bpo70+1 and enabled IPsec using AES-CCM, but I have a good feeling this is the fix. -- Gerald Turner Email: gtur...@unzane.com JID: gtur...@unzane.com GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 pgpY7lajijCWn.pgp Description: PGP signature
