Re: How to revoke Debian kernels for secure boot
Hey all, On Wed, Dec 13, 2023 at 10:18:40PM +, Dimitri John Ledkov wrote: >At the moment the best options are: > >- rotate online signing key >- build new shim with old signing key in vendorx (revoked ESL) >- build new kernels with old signing key built-in revoked keyring > >This is to ensure that old shim & old kernel can boot or kexec new kernels. >To ensure new shim cannot boot old kernels. >To ensure that new kernels cannot kexec old kernels. Yes, this is roughly what I was thinking too. Thanks for explaining it well here. Something else we should *also* be doing is starting public documentation on what changes we've made to signing over time, tracking keys, revocations etc. so that: * users have a chance to understand what's changed and why * (being honest!) *developers* have a record so we can remember too I'm not sure the wiki is the best place for this, but I'm also not sure this should live on the main www.d.o either. Suggestions? >This is revocation strategy used by Canonical Kernel Team for Ubuntu Kernels. ACK, makes sense. >There is no sbat for kernels yet (and/or nobody has yet started to use sbat for >kernels). It's a difficult thing to do, especially in light of significant pushback from upstream developers. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Re: [arm64] secure boot breach via VFIO_NOIOMMU
On Thu, Dec 14, 2023 at 09:26:09AM +0100, Salvatore Bonaccorso wrote: >Hi, > >On Wed, Dec 13, 2023 at 10:45:01PM +0100, Bastian Blank wrote: >> Hi >> >> Over six years ago, support for VFIO without IOMMU was enabled for >> arm64. This is a breach of the integrity lockdown requirement of secure >> boot. >> >> VFIO is a framework for handle devices in userspace. To make >> this safe, an IOMMU is required by default. Without it, user space can >> write everywhere in memory. The code is still not conditional on >> lockdown, even if a patch was proposed. >> >> I intend to disable this option for all supported kernels. Definitely. >Agreed. > >For the readers reading this along, this was raised in context of >https://salsa.debian.org/kernel-team/linux/-/merge_requests/925#note_446730 >and >https://salsa.debian.org/kernel-team/linux/-/merge_requests/502#note_315464 > >The proposed patch felt probably trough the cracks. Nod. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Re: No longer sign i386 kernels
On Wed, Dec 06, 2023 at 11:44:52PM +0100, Pascal Hambourg wrote: >Hello, > >On 06/12/2023 at 22:09, Steve McIntyre wrote: >> >> On Wed, Dec 06, 2023 at 06:01:17PM +0100, Bastian Blank wrote: >> > >> > I would like do stop signing i386 kernels. >> > >> > - IA32 UEFI is basically non existent outside of the Apple world and >> > maybe some embedded stuff. >(...) >> there's no point in signing i386 grub and fwupd or >> having a signed shim if we don't have a signed kernel. > >Over the years I have seen a number of netbook or tablet-style PCs with >32-bit UEFI firmware and a 64-bit capable CPU, so they could boot with >grub-efi-ia32 and an amd64 kernel. I do not remember if they supported secure >boot though. Some of them did, but at this point the most recent of those Bay Trail netbooks is heading for a decade old. They were designed to be very cheap, which means very few will have survived this long. We're not proposing to kill support *altogether*, but SB isn't a priority here for such old machines IMHO. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Re: No longer sign i386 kernels
Hey Bastian! On Wed, Dec 06, 2023 at 06:01:17PM +0100, Bastian Blank wrote: > >I would like do stop signing i386 kernels. > >- IA32 UEFI is basically non existent outside of the Apple world and > maybe some embedded stuff. >- i386 lacks many of the microarchitectural fixes that creeped in during > the last years. So those kernels are unsuitable for real world usage > of processors released in the last ten years. > >Install base of a IA32 EFI capable boot chain, as possible to see by >popcon (via grub-efi-ia32-signed): 178 > >Install base of a X64 EFI capable boot chain (via >grub-efi-amd64-signed): 71743 ACK. We're heading towards deprecating i386 as a full architecture anyway and just keeping it as a secondary arch for backwards compatibility for old programs, Wine, games etc. So I think this makes sense. We should publicise this for users and be consistent for all the EFI signed binaries - there's no point in signing i386 grub and fwupd or having a signed shim if we don't have a signed kernel. Agreed? -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Bug#1032362: Kernel doesn't find SATA ports on Softiron 1000 (arm64 Seattle)
On Sun, Mar 05, 2023 at 12:09:24AM +, Steve McIntyre wrote: >Source: linux >Version: 6.1.12-1 >Severity: important > >Hey folks, > >I've just upgraded my Seattle-based system to bookworm and it no >longer finds the onboard AHCI SATA storage so it stops at an initramfs >prompt. Going back to the current bullseye kernel (5.10.162-1), it all >works just fine. > >As far as I can see, the DTB hasn't changed in this area. The >non-booting system still has plausible-looking entries for the sATA >controllers: > >drwxr-xr-x2 000 Mar 5 00:00 >/sys/firmware/devicetree/base/smb/sata@e030 >drwxr-xr-x2 000 Mar 5 00:00 >/sys/firmware/devicetree/base/smb/sata@e0d0 > >I'll try to bisect and see where things stopped working... The failure appears in between Linux maul 6.0.0-6-arm64 #1 SMP Debian 6.0.12-1 (2022-12-09) aarch64 GNU/Linux and Linux (none) 6.1.0-0-arm64 #1 SMP Debian 6.1~rc3-1~exp1 (2022-11-02) aarch64 GNU/Linux A quick look at the output of "git diff -r debian/6.0.12-1..debian/6.1_rc3-1_exp1" in the debian linux tree doesn't show me anything likely, BICBW. Adding a CC to the debian-arm list in case any of our friendly local ARM kernel folks might be able to help... -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Bug#1032362: Kernel doesn't find SATA ports on Softiron 1000 (arm64 Seattle)
Source: linux Version: 6.1.12-1 Severity: important Hey folks, I've just upgraded my Seattle-based system to bookworm and it no longer finds the onboard AHCI SATA storage so it stops at an initramfs prompt. Going back to the current bullseye kernel (5.10.162-1), it all works just fine. As far as I can see, the DTB hasn't changed in this area. The non-booting system still has plausible-looking entries for the sATA controllers: drwxr-xr-x2 000 Mar 5 00:00 /sys/firmware/devicetree/base/smb/sata@e030 drwxr-xr-x2 000 Mar 5 00:00 /sys/firmware/devicetree/base/smb/sata@e0d0 I'll try to bisect and see where things stopped working... -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Shim and secure boot status, leading up to bookworm
Hi Jeremy, On Wed, Jan 25, 2023 at 12:40:07PM -0700, Jeremy Hall wrote: > >When things get built, will there be a path forward for people who >might need grub modules like serial console for accessibility reasons? The serial module has already been added to the signed grub binary a while back (2.06-4). If you need anything else, please ask or file bugs. In the longer term, some grub upstream developers are working on adding support for signing grub modules individually that might make it possible for people to add more themselves. But that's not going to happen before bookworm. HTH! -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Re: Shim and secure boot status, leading up to bookworm
Hey Antonio, On Wed, Jan 25, 2023 at 04:17:50PM -0300, Antonio Terceiro wrote: >On Wed, Jan 25, 2023 at 06:11:45PM +0000, Steve McIntyre wrote: >> >> The MS and cert issues are now both resolved, and I'm now working on a >> shim *15.7* upload. There's a little more work and testing to do, but >> I'm not far off. Yay? > >Have the issues with arm64 been fixed? Will this release provide a >signed arm64 shim? We should have a signed shim for arm64, yes. I need to test end to end again yet; I think we're still missing some arm64 SB patches for grub. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Rarely is anyone thanked for the work they did to prevent the disaster that didn’t happen.” -- Mikko Hypponen (https://twitter.com/mikko/)
Shim and secure boot status, leading up to bookworm
Hey all! Here's a status update and plans for SB and shim. If any of this is unclear or you have doubts, please say! We currently have *signed* shim *15.4* packages in the archive, for all of buster, bullseye, bookworm and sid. That works OK at the moment, but is getting old (July 2021) and needs updating soonish. I uploaded shim *15.6* in July 2022 and we attempted to get that signed too. Reviews were positive, but due to process problems around Microsoft uploads and then a long delay on getting a needed EV certificate renewed we never managed to get that signed. :-( The MS and cert issues are now both resolved, and I'm now working on a shim *15.7* upload. There's a little more work and testing to do, but I'm not far off. Yay? However, there are a couple of caveats to this... SBAT update --- The new shim build will need to block SB execution of older grub builds (anything with an SBAT level for grub.debian < 4). The oldest builds that will continue to work are: * 2.06-6 (unstable/bookworm) * 2.06-3~deb11u5 (bullseye) * 2.06-3~deb10u3 (buster) This is hopefully not unexpected, but I'm sharing here to be 100% clear. I'm planning on doing shim 15.7 builds for bullseye and buster again, so these all matter here. NX -- At the end of November 2022 (while unable to get anything signed) we passed a deadline; new shims since that point must be built with NX support enabled, and flagged as such. This extra hardening should improve security more, so it's not a bad thing in general. *However*, it does have consequences - once shim is loaded by UEFI firmware and started with NX enabled, all the UEFI binaries downstream of it *also* have to support NX as well. Patches for grub and linux are under discussion at the moment, but AFAIK not yet released; I need to check on the status of fwupd-efi too. What does this mean for us? * Older machines with older firmware will continue to work just fine. * New-enough machines with firmware that enables NX will fail to boot until we get full NX support through our boot chain. :-( There's a mitigating factor here: *such* new machines may already reject our older signed binaries anyway. We're stuck in a bad situation here I'm afraid; I think the only sensible way is forward, applying NX patches as soon as they're ready. Thoughts? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian" signature.asc Description: PGP signature
Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye
On Sat, Sep 04, 2021 at 06:50:16PM +0100, Steve McIntyre wrote: > >I have a synquacer here still and I'll take a look. I noticed on >bullseye release day that USB stuff didn't seem to work in the >installer on the synquacer either. Maybe there's been a regression in >config. :-/ > >I'll take a look... Hmmm, booting 5.10.0-0.bpo.8-arm64 here does not work at all. I'm seeing a lot of errors around DMA setup, e.g.: [0.142797] OF: translation of DMA address(0) to CPU address failed node() [0.142824] sram 4520.sram: Invalid size 0x1 for dma-range(s) [0.142991] OF: translation of DMA address(0) to CPU address failed node() [0.143008] uart-pl011 2a40.uart: Invalid size 0x1 for dma-range(s) ... [3.843964] OF: translation of DMA address(0) to CPU address failed node() [3.850875] armv8-pmu pmu: Invalid size 0x1 for dma-range(s) [3.857518] hw perfevents: enabled with armv8_pmuv3 PMU driver, 7 counters available ... [3.954986] OF: translation of DMA address(0) to CPU address failed node() ... [4.391564] OF: translation of DMA address(0) to CPU address failed node() [4.398449] pcieport :00:00.0: Invalid size 0x1 for dma-range(s) [4.405253] OF: translation of DMA address(0) to CPU address failed node() [4.412161] pcieport :01:01.0: Invalid size 0x1 for dma-range(s) [4.418885] OF: translation of DMA address(0) to CPU address failed node() [4.425778] pcieport :01:03.0: Invalid size 0x1 for dma-range(s) [4.432487] OF: translation of DMA address(0) to CPU address failed node() [4.439385] pcieport :01:05.0: Invalid size 0x1 for dma-range(s) [4.446095] OF: translation of DMA address(0) to CPU address failed node() [4.452988] pcieport :01:07.0: Invalid size 0x1 for dma-range(s) [4.459693] pci :04:00.0: enabling device ( -> 0002) [4.465488] OF: translation of DMA address(0) to CPU address failed node() ... [4.472385] pci-host-generic 7000.pcie: Invalid size 0x1 for dma-range(s) Shortly after this, I see looping errors in the sdhci driver: [5.728589] xhci_hcd: probe of :04:00.0 failed with error -12 [5.734347] sp : 8000142bbb10 [5.734351] x29: 8000142bbb10 x28: [5.734358] x27: 000801ebf848 x26: [5.768201] x25: 0080 x24: 0001 [5.773514] x23: 00080176ac10 x22: 000889b60080 [5.778826] x21: x20: [5.784139] x19: 8000117c9788 x18: 0020 [5.789451] x17: 00080833da00 x16: 0080 [5.794763] x15: x14: 2820776f6c667265 [5.800076] x13: 766f203633353536 x12: 2b66 [5.805389] x11: x10: 6678302072646461 [5.810701] x9 : 80001011159c x8 : 62202c66 [5.816013] x7 : 66206b73616d x6 : 00087f4647c0 [5.821325] x5 : 8000142bb828 x4 : [5.826637] x3 : x2 : [5.831949] x1 : 3082d45f0379e900 x0 : [5.837262] Call trace: [5.839708] swiotlb_map+0x294/0x2a8 [5.843281] dma_map_page_attrs+0xec/0x228 [5.847382] sdhci_setup_host+0xa8c/0xee8 [sdhci] [5.852086] sdhci_add_host+0x20/0x58 [sdhci] [5.856444] sdhci_f_sdh30_probe+0x2a8/0x380 [sdhci_f_sdh30] [5.862104] platform_drv_probe+0x5c/0xb0 [5.866113] really_probe+0xf0/0x4d8 [5.869686] driver_probe_device+0xfc/0x168 [5.873868] __driver_attach_async_helper+0xbc/0xc8 [5.878743] async_run_entry_fn+0x50/0x218 [5.882837] process_one_work+0x1bc/0x480 [5.886843] worker_thread+0x158/0x4e0 [5.890590] kthread+0x12c/0x130 [5.893817] ret_from_fork+0x10/0x30 [5.897389] ---[ end trace 986b9b1a11578595 ]--- Longer log attached. I'm wondering if there's a DTB mismatch or something - my system here is still using the built-in DTB from the EFI firmware, and I don't see a newer DTB available in the debian package nor in upstream git. @Arnd any clues please? -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183 synquacer.log.gz Description: application/gzip
Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye
Hey Luca! On Fri, Sep 03, 2021 at 03:50:52PM -0700, Don Armstrong wrote: >Control: reassign -1 linux-signed-arm64 >Control: found -1 5.10.46+4, 5.10.46+4~bpo10+1 >Control: tag -1 moreinfo >Control: severity -1 important > > >On Fri, 03 Sep 2021, Luca Di Stefano wrote: >> A few days ago I tried to upgrade one of the six Socionext SynQuacers >> that we have to the latest Debian release. >> >> It was running fine on Buster using the 4.19 kernel and had no previous >> issues. > >[...] > >> The next boot sequence would start and get to the point where it would >> look for the rootfs without finding it and going into initramfs >> >> I've then proceeded to reinstall buster on that machine and it just >> worked fine, then also tried installing the kernel from backports >> linux- image-5.10.0-0.bpo.8-arm64 and after reboot it caused the same >> problem not finding the rootfs and going into initramfs. > >I'm not familiar with the hardware of this particular device, but I >suspect that some necessary driver was (likely inadvertently) excluded >from the configuration of the 5.10 kernel, but included in 4.19. > >Looking at the output from the boot of both kernels should give you an >idea of what module/device is broken, and providing that to this bug >will give one of the maintainers of the arm64 kernel a chance of helping >fix the issue. I have a synquacer here still and I'll take a look. I noticed on bullseye release day that USB stuff didn't seem to work in the installer on the synquacer either. Maybe there's been a regression in config. :-/ I'll take a look... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Bug#992238: debian-installer: Installation fails on HP ProLiant m400 Server: additional cores crash, kernel hangs in acpi_init
On Mon, Aug 16, 2021 at 01:24:14PM +0200, Justus Winter wrote: >Steve McIntyre writes: >> >> OK, and my upgrade worked just fine. The key difference that I'm >> seeing is that on my system ACPI is *not* used: >> >> root@mustang4:/home/steve# grep ACPI /var/log/syslog >> Aug 16 11:20:27 mustang4 kernel: [0.00] efi: ACPI=0x43fa70 ACPI >> 2.0=0x43fa700014 SMBIOS 3.0=0x43fa9db000 ESRT=0x43ff006d18 >> MOKvar=0x43fd2b2000 MEMRESERVE=0x43fa5e0718 >> Aug 16 11:20:27 mustang4 kernel: [1.293700] ACPI: Interpreter disabled. >> Aug 16 11:20:27 mustang4 kernel: [1.322457] pnp: PnP ACPI: disabled >> >> Basically, the firmware on these older machines is too old for ACPI to >> work well. This brings back memories of X-Gene 1 oddities - the way >> they boot the extra CPU cores depends on specific setup in the DTB. My >> machine is working that way, but I'm guessing that maybe whatever in >> the kernel determines this is *not* automatically disabling ACPI on >> your machine. >> >> Pondering: do things work better for you if you add "acpi=off" to the >> kernel command line? > >Interesting. Yeah, I actually tried that last week, but it failed: :-( Argh. Oh wow, just noticed: >U-Boot 2013.04 (Oct 02 2015 - 14:44:51) I moved all my Mustangs over to UEFI (edk2) rather than U-Boot, but I honestly don't know if that's an option for the m400. ... >[0.00] Kernel command line: BOOT_IMAGE=/debian-installer/arm64/linux >--- console=ttyS0,115200 earlycon=uart,mmio32,0x1c021000 initcall_debug >keep_bootcon efi=debug debug earlyprintk=efi,keep acpi=off >[0.00] Dentry cache hash table entries: 8388608 (order: 14, 67108864 >bytes, linear) >[0.00] Inode-cache hash table entries: 4194304 (order: 13, 33554432 >bytes, linear) >[0.00] mem auto-init: stack:off, heap alloc:on, heap free:off >[0.00] software IO TLB: mapped [mem >0x0040f800-0x0040fc00] (64MB) >[0.00] Memory: 5107712K/67104768K available (11776K kernel code, 2436K >rwdata, 7008K rodata, 5440K init, 598K bss, 1407976K reserved, 65536K >cma-reserved) >[0.00] random: get_random_u64 called from >__kmem_cache_create+0x38/0x560 with crng_init=0 >[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 >[0.00] ftrace: allocating 38533 entries in 151 pages >[0.00] ftrace: allocated 151 pages with 5 groups >[0.00] rcu: Hierarchical RCU implementation. >[0.00] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1. >[0.00] Rude variant of Tasks RCU enabled. >[0.00] Tracing variant of Tasks RCU enabled. >[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 >jiffies. >[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 >[0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 >[0.00] Kernel panic - not syncing: No interrupt controller found. >[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-8-arm64 #1 >Debian 5.10.46-3 >[0.00] Call trace: >[0.00] dump_backtrace+0x0/0x1e4 >[0.00] show_stack+0x24/0x30 >[0.00] dump_stack+0xd0/0x12c >[0.00] panic+0x168/0x370 >[0.00] init_IRQ+0xe8/0x104 >[0.00] start_kernel+0x3a8/0x5ac >[0.00] ---[ end Kernel panic - not syncing: No interrupt controller >found. ]--- OK, this is not looking good. I'll ask some of the Arm folks to have a look here in case they can help. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Bug#992238: debian-installer: Installation fails on HP ProLiant m400 Server: additional cores crash, kernel hangs in acpi_init
On Mon, Aug 16, 2021 at 12:54:47PM +0200, Justus Winter wrote: >Steve McIntyre writes: >> On Mon, Aug 16, 2021 at 10:09:49AM +0200, Justus Winter wrote: >>>Package: debian-installer >>>Version: 20210731 >>>Severity: critical >>>Tags: d-i >>>Justification: breaks the whole system >>> >>>Dear Maintainer, >>> >>>I'm trying to install Debian Bullseye on a ProLiant m400 Server >>>Cartridge. The cartridge is in EFI mode, we boot the EFI shim, GRUB, >>>the kernel, and the netboot initrd via PXE and tftp. We added the >>>necessary kernel command line flags to redirect the kernel log to the >>>serial console early on, and various debugging flags. >>> >>>Reading the log we believe that there are two problems. First, while >>>bringing up additional CPU cores, we see them crash immediately. >>>Adding nosmp to the kernel command line avoids this, but doesn't make >>>the second problem go away. Second, the kernel calls acpi_init, which >>>does not seem to return. >> >> Hmmm. The m400 sleds are getting quite old, and AIUI they're basically >> EOL in terms of firmware support etc. > >Well, I'm also getting quite old, yet, I'd like to use Debian :) Sure. :-) >> I've got some Mustang (X-Gene 1) machines here, which are the same >> core APM hardware but packaged on standard motherboard (mini-itx I >> think?). I'm just trying a bullseye update on one now. > >Thanks. OK, and my upgrade worked just fine. The key difference that I'm seeing is that on my system ACPI is *not* used: root@mustang4:/home/steve# grep ACPI /var/log/syslog Aug 16 11:20:27 mustang4 kernel: [0.00] efi: ACPI=0x43fa70 ACPI 2.0=0x43fa700014 SMBIOS 3.0=0x43fa9db000 ESRT=0x43ff006d18 MOKvar=0x43fd2b2000 MEMRESERVE=0x43fa5e0718 Aug 16 11:20:27 mustang4 kernel: [1.293700] ACPI: Interpreter disabled. Aug 16 11:20:27 mustang4 kernel: [1.322457] pnp: PnP ACPI: disabled Basically, the firmware on these older machines is too old for ACPI to work well. This brings back memories of X-Gene 1 oddities - the way they boot the extra CPU cores depends on specific setup in the DTB. My machine is working that way, but I'm guessing that maybe whatever in the kernel determines this is *not* automatically disabling ACPI on your machine. Pondering: do things work better for you if you add "acpi=off" to the kernel command line? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38
I came to this bug report when searching for other things; I've read through the history here and I feel compelled to comment. Jim: given your appalling lack of respect you've shown for Debian developers here, it's hardly surprising that nobody seems to want to engage with you. Your tone and wording in several of your messages here are utterly unacceptable. You've used abusive language about people who are volunteers working to improve Debian in their own time. I would strongly suggest that you revisit what you've written and consider apologising. -- Steve McIntyre 93...@debian.org Debian Community Team commun...@debian.org
Re: Firmware testing images broken
On Thu, Sep 17, 2020 at 07:25:36PM +0100, Ben Hutchings wrote: >On Tue, 2020-09-15 at 10:01 +0100, Steve McIntyre wrote: >> >> And fixed as of today's daily builds. >> >> Thanks for the report! > >Thanks Steve. We probably should have thought to update that after >changing the dependencies (which was needed because the module >dependencies changed). ACK - some warning might have been nice. Meh, no biggie... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
On Fri, Jun 26, 2020 at 10:29:28AM -0700, John Johansen wrote:
>On 6/26/20 9:50 AM, Steve McIntyre wrote:
>>
>> OK, will try that second...
>>
>
>I have not been able to reproduce but
>
>So looking at linux-4.19.y it looks like
>1f8266ff5884 apparmor: don't try to replace stale label in ptrace access check
>
>was picked without
>ca3fde5214e1 apparmor: don't try to replace stale label in ptraceme check
>
>Both of them are marked as
>Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
>
>so I would expect them to be picked together.
>
>ptraceme is potentially updating the task's cred while the access check is
>running.
>
>Try building after picking
>ca3fde5214e1 apparmor: don't try to replace stale label in ptraceme check
Bingo! With that one change the test suite runs to completion, no lockup.
\o/
Thanks guys, I think we've found the cause here.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, and wiser people so full of doubts."
-- Bertrand Russell
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
Hi again, On Fri, Jun 26, 2020 at 05:50:00PM +0100, Steve McIntyre wrote: >On Fri, Jun 26, 2020 at 04:25:59PM +0200, Jann Horn wrote: >>On Fri, Jun 26, 2020 at 3:41 PM Greg KH wrote: >>> On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote: > >... > >>> > Considering I'm running strace build tests to provoke this bug, >>> > finding the failure in a commit talking about ptrace changes does look >>> > very suspicious...! >>> > >>> > Annoyingly, I can't reproduce this on my disparate other machines >>> > here, suggesting it's maybe(?) timing related. >> >>Does "hard lockup" mean that the HARDLOCKUP_DETECTOR infrastructure >>prints a warning to dmesg? If so, can you share that warning? > >I mean the machine locks hard - X stops updating, the mouse/keyboard >stop responding. No pings, etc. When I reboot, there's nothing in the >logs. > >>If you don't have any way to see console output, and you don't have a >>working serial console setup or such, you may want to try re-running >>those tests while the kernel is booted with netconsole enabled to log >>to a different machine over UDP (see >>https://www.kernel.org/doc/Documentation/networking/netconsole.txt). > >ACK, will try that now for you. > >>You may want to try setting the sysctl kernel.sysrq=1 , then when the >>system has locked up, press ALT+PRINT+L (to generate stack traces for >>all active CPUs from NMI context), and maybe also ALT+PRINT+T and >>ALT+PRINT+W (to collect more information about active tasks). > >Nod. > >>(If you share stack traces from these things with us, it would be >>helpful if you could run them through scripts/decode_stacktrace.pl >>from the kernel tree first, to add line number information.) > >ACK. Output passed through scripts/decode_stacktrace.sh attached. Just about to try John's suggestion next. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject tack.log.decoded.gz Description: application/gzip
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
Hi Jann, On Fri, Jun 26, 2020 at 04:25:59PM +0200, Jann Horn wrote: >On Fri, Jun 26, 2020 at 3:41 PM Greg KH wrote: >> On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote: ... >> > Considering I'm running strace build tests to provoke this bug, >> > finding the failure in a commit talking about ptrace changes does look >> > very suspicious...! >> > >> > Annoyingly, I can't reproduce this on my disparate other machines >> > here, suggesting it's maybe(?) timing related. > >Does "hard lockup" mean that the HARDLOCKUP_DETECTOR infrastructure >prints a warning to dmesg? If so, can you share that warning? I mean the machine locks hard - X stops updating, the mouse/keyboard stop responding. No pings, etc. When I reboot, there's nothing in the logs. >If you don't have any way to see console output, and you don't have a >working serial console setup or such, you may want to try re-running >those tests while the kernel is booted with netconsole enabled to log >to a different machine over UDP (see >https://www.kernel.org/doc/Documentation/networking/netconsole.txt). ACK, will try that now for you. >You may want to try setting the sysctl kernel.sysrq=1 , then when the >system has locked up, press ALT+PRINT+L (to generate stack traces for >all active CPUs from NMI context), and maybe also ALT+PRINT+T and >ALT+PRINT+W (to collect more information about active tasks). Nod. >(If you share stack traces from these things with us, it would be >helpful if you could run them through scripts/decode_stacktrace.pl >from the kernel tree first, to add line number information.) ACK. >Trying to isolate the problem: > >__end_current_label_crit_section and end_current_label_crit_section >are aliases of each other (via #define), so that line change can't >have done anything. > >That leaves two possibilities AFAICS: > - the might_sleep() call by itself is causing issues for one of the >remaining users of begin_current_label_crit_section() (because it >causes preemption to happen more often where it didn't happen on >PREEMPT_VOLUNTARY before, or because it's trying to print a warning >message with the runqueue lock held, or something like that) > - the lack of "if (aa_replace_current_label(label) == 0) >aa_put_label(label);" in __begin_current_label_crit_section() is >somehow causing issues > >You could try to see whether just adding the might_sleep(), or just >replacing the begin_current_label_crit_section() call with >__begin_current_label_crit_section(), triggers the bug. > > >If you could recompile the kernel with CONFIG_DEBUG_ATOMIC_SLEEP - if >that isn't already set in your kernel config -, that might help track >down the problem, unless it magically makes the problem stop >triggering (which I guess would be conceivable if this indeed is a >race). OK, will try that second... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
On Fri, Jun 26, 2020 at 02:45:18PM +0100, Steve McIntyre wrote: >Hey Greg, > >On Fri, Jun 26, 2020 at 03:41:32PM +0200, Greg KH wrote: >>On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote: >>> >>> e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit >>> commit e58f543fc7c0926f31a49619c1a3648e49e8d233 >>> Author: Jann Horn >>> Date: Thu Sep 13 18:12:09 2018 +0200 > >... > >>> Annoyingly, I can't reproduce this on my disparate other machines >>> here, suggesting it's maybe(?) timing related. >>> >>> Hope this helps - happy to give more information, test things, etc. >> >>So if you just revert this one patch, all works well? > >Correct. > >>I've added the authors of the patch to the cc: list... >> >>Also, does this problem happen on Linus's tree? > >Just building to check that now... Current head here (3e08a95294a4fb3702bb3d35ed08028433c37fe6) works fine. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
Hey Greg, On Fri, Jun 26, 2020 at 03:41:32PM +0200, Greg KH wrote: >On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote: >> >> e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit >> commit e58f543fc7c0926f31a49619c1a3648e49e8d233 >> Author: Jann Horn >> Date: Thu Sep 13 18:12:09 2018 +0200 ... >> Annoyingly, I can't reproduce this on my disparate other machines >> here, suggesting it's maybe(?) timing related. >> >> Hope this helps - happy to give more information, test things, etc. > >So if you just revert this one patch, all works well? Correct. >I've added the authors of the patch to the cc: list... > >Also, does this problem happen on Linus's tree? Just building to check that now... -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
Hi folks,
I'm the maintainer in Debian for strace. Trying to reproduce
https://bugs.debian.org/963462 on my machine (Thinkpad T470), I've
found a repeatable hard lockup running the strace testsuite. Each time
it seems to have failed in a slightly different place in the testsuite
(suggesting it's not one particular syscall test that's triggering the
failure). I initially found this using Debian's current Buster kernel
(4.19.118+2+deb10u1), then backtracking I found that 4.19.98+1+deb10u1
worked fine.
I've bisected to find the failure point along the linux-4.19.y stable
branch and what I've got to is the following commit:
e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit
commit e58f543fc7c0926f31a49619c1a3648e49e8d233
Author: Jann Horn
Date: Thu Sep 13 18:12:09 2018 +0200
apparmor: don't try to replace stale label in ptrace access check
[ Upstream commit 1f8266ff58840d698a1e96d2274189de1bdf7969 ]
As a comment above begin_current_label_crit_section() explains,
begin_current_label_crit_section() must run in sleepable context because
when label_is_stale() is true, aa_replace_current_label() runs, which uses
prepare_creds(), which can sleep.
Until now, the ptrace access check (which runs with a task lock held)
violated this rule.
Also add a might_sleep() assertion to begin_current_label_crit_section(),
because asserts are less likely to be ignored than comments.
Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
Signed-off-by: Jann Horn
Signed-off-by: John Johansen
Signed-off-by: Sasha Levin
:04 04 ca92f885a38c1747b812116f19de6967084a647e
865a227665e460e159502f21e8a16e6fa590bf50 M security
Considering I'm running strace build tests to provoke this bug,
finding the failure in a commit talking about ptrace changes does look
very suspicious...!
Annoyingly, I can't reproduce this on my disparate other machines
here, suggesting it's maybe(?) timing related.
Hope this helps - happy to give more information, test things, etc.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
kittens, except the kittens randomly appear and disappear because they
have day jobs." -- Matt Mackall
Bug#963493: Repeatable hard lockup running strace testsuite using 4.19.118+2+deb10u1, 4.19.98+1+deb10u1 works fine
OK, so I've just bisected down the stable 4.19.y branch from 4.19.98
to 4.19.118. What I've found is:
e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit
commit e58f543fc7c0926f31a49619c1a3648e49e8d233
Author: Jann Horn
Date: Thu Sep 13 18:12:09 2018 +0200
apparmor: don't try to replace stale label in ptrace access check
[ Upstream commit 1f8266ff58840d698a1e96d2274189de1bdf7969 ]
As a comment above begin_current_label_crit_section() explains,
begin_current_label_crit_section() must run in sleepable context because
when label_is_stale() is true, aa_replace_current_label() runs, which uses
prepare_creds(), which can sleep.
Until now, the ptrace access check (which runs with a task lock held)
violated this rule.
Also add a might_sleep() assertion to begin_current_label_crit_section(),
because asserts are less likely to be ignored than comments.
Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
Signed-off-by: Jann Horn
Signed-off-by: John Johansen
Signed-off-by: Sasha Levin
:04 04 ca92f885a38c1747b812116f19de6967084a647e
865a227665e460e159502f21e8a16e6fa590bf50 M security
Considering I'm running strace build tests to provoke this bug,
finding the failure in a commit talking about ptrace changes does look
very suspicious...!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Bug#963493: Repeatable hard lockup running strace testsuite using 4.19.118+2+deb10u1, 4.19.98+1+deb10u1 works fine
On Wed, Jun 24, 2020 at 05:39:38PM +0100, Steve McIntyre wrote:
>On Wed, Jun 24, 2020 at 05:57:42PM +0200, Salvatore Bonaccorso wrote:
>>Control: found -1 4.19.118-1
>>Control: tags -1 + upstream
>>
>>>
>>> As I can reproduce this quite easily, I'm happy to help with whatever
>>> debugging might be useful.
>>
>>This sounds familiar to
>>https://lore.kernel.org/stable/7231ea1a-70b2-c156-1724-2357ed10b...@intel.com/
>>
>>d3ec10aa9581 ("KEYS: Don't write out to userspace while holding key
>>semaphore") was backported to v4.19.y in 4.19.118. The issue seems to
>>be fixed with 4f0882491a14 ("KEYS: Avoid false positive ENOMEM error
>>on key read") which was backported to 4.19.119.
>>
>>Can you check if cherry-picking the above commit
>>(e4a281c7daa07814748179ee8b4b483124bb94ea in the linux-4.19.y) fixes
>>the issue?
>
>Sure, building it now to test.
Unfortunately, no joy. :-( Same lockup at a random point in the test
suite.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess
Bug#963493: Repeatable hard lockup running strace testsuite using 4.19.118+2+deb10u1, 4.19.98+1+deb10u1 works fine
Hey Salvatore! On Wed, Jun 24, 2020 at 05:57:42PM +0200, Salvatore Bonaccorso wrote: >Control: found -1 4.19.118-1 >Control: tags -1 + upstream > >Hi Steve, > >On Mon, Jun 22, 2020 at 12:58:35PM +0100, Steve McIntyre wrote: >> Source: linux >> Version: 4.19.118-2+deb10u1 >> Severity: serious >> >> Hi folks, >> >> Trying to reproduce #963462 on my Thinkpad T470, I'm repeatedly >> getting a hard lockup running the strace testsuite. I've done this 4 >> times to be sure. Each time it seems to have failed in a slightly >> different place in the testsuite (suggesting it's not one particular >> syscall test that's triggering the failure). Only one of the 4 lockups >> left eny evidence in the logs (reproduced below), so I'm not sure if >> the error here is actually the root of the problem or not. :-/ >> >> The machine is not noticeably running hot or anything while doing >> these tests. >> >> Rebooting back to 4.19.0-8-amd64 (aka 4.9.98+1+deb10u1), I've just run >> the same testsuite twice in a row and it ran to completion with no >> lockup. >> >> Here's the one bit of log that I did get, in case it's useful. >> >> Jun 22 11:36:49 tack kernel: [ 318.195906] futex_wake_op: futex tries to >> shift op by -849; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195910] futex_wake_op: futex tries to >> shift op by -849; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195971] futex_wake_op: futex tries to >> shift op by -518; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195974] futex_wake_op: futex tries to >> shift op by -518; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195977] futex_wake_op: futex tries to >> shift op by -1; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195979] futex_wake_op: futex tries to >> shift op by -1; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.199661] futex_wake_op: futex tries to >> shift op by -849; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.199674] futex_wake_op: futex tries to >> shift op by -849; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.199917] futex_wake_op: futex tries to >> shift op by -518; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.199982] futex_wake_op: futex tries to >> shift op by -518; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.398755] L1TF CPU bug present and SMT on, >> data leak possible. See CVE-2018-3646 and >> https://www.kernel.org/doc/html/latest/admin-gui >> de/hw-vuln/l1tf.html for details. >> Jun 22 11:36:49 tack kernel: [ 318.587324] WARNING: CPU: 2 PID: 32174 at >> mm/page_alloc.c:4385 __alloc_pages_nodemask+0x241/0x2b0 >> Jun 22 11:36:49 tack kernel: [ 318.587326] Modules linked in: acpi_call(OE) >> ipt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter >> nft_chain_nat_ipv4 nf_ >> nat_ipv4 xt_addrtype nft_compat xt_conntrack nf_nat nf_conntrack >> nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp overlay devlink >> cpufreq_userspace cpufreq_conser >> vative cpufreq_powersave ipmi_devintf ipmi_msghandler nf_tables nfnetlink >> appletalk psnap llc ax25 pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) >> vboxdrv(OE) cmac >> bnep fuse binfmt_misc pktcdvd snd_hda_codec_hdmi btusb btrtl btbcm btintel >> bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 >> videobuf2_common snd_hd >> a_codec_realtek snd_hda_codec_generic videodev media drbg ansi_cprng >> ecdh_generic nls_ascii nls_cp437 vfat fat arc4 intel_rapl snd_soc_skl msr >> snd_soc_skl_ipc snd_soc_ >> sst_ipc >> Jun 22 11:36:49 tack kernel: [ 318.587344] snd_soc_sst_dsp >> x86_pkg_temp_thermal intel_powerclamp snd_hda_ext_core coretemp >> snd_soc_acpi_intel_match iwlmvm snd_soc_ac >> pi kvm_intel snd_soc_core mac80211 snd_compress wmi_bmof i915 snd_hda_intel >> iwlwifi kvm snd_hda_codec snd_h >> da_core irqbypass snd_hwdep evdev intel_cstate joydev snd_pcm_oss >> drm_kms_helper intel_uncore serio_raw intel_rapl_perf mei_me snd_mixer_oss >> cfg80211 sg efi_pstore drm pcspkr mei efivars snd_pcm ucsi_acpi snd_timer >> typec_ucsi i2c_algo_bit iTCO_wdt iTCO_vendor_support intel_pch_thermal typec >> thinkpad_acpi tpm_crb wmi nvram snd soundcore tpm_tis rfkill video >> tpm_tis_core battery pcc_cpufreq ac tpm rng_core acpi_pad button parport_pc >> nfsd ppdev auth_rpcgss lp nfs_acl lockd grace sunrpc parport efivarfs >> ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic >> Jun 22 11:36:49 tack kernel: [ 318.587362] fscrypto ecb btrfs
Bug#963493: Repeatable hard lockup running strace testsuite using 4.19.118+2+deb10u1, 4.19.98+1+deb10u1 works fine
Source: linux Version: 4.19.118-2+deb10u1 Severity: serious Hi folks, Trying to reproduce #963462 on my Thinkpad T470, I'm repeatedly getting a hard lockup running the strace testsuite. I've done this 4 times to be sure. Each time it seems to have failed in a slightly different place in the testsuite (suggesting it's not one particular syscall test that's triggering the failure). Only one of the 4 lockups left eny evidence in the logs (reproduced below), so I'm not sure if the error here is actually the root of the problem or not. :-/ The machine is not noticeably running hot or anything while doing these tests. Rebooting back to 4.19.0-8-amd64 (aka 4.9.98+1+deb10u1), I've just run the same testsuite twice in a row and it ran to completion with no lockup. Here's the one bit of log that I did get, in case it's useful. Jun 22 11:36:49 tack kernel: [ 318.195906] futex_wake_op: futex tries to shift op by -849; fix this program Jun 22 11:36:49 tack kernel: [ 318.195910] futex_wake_op: futex tries to shift op by -849; fix this program Jun 22 11:36:49 tack kernel: [ 318.195971] futex_wake_op: futex tries to shift op by -518; fix this program Jun 22 11:36:49 tack kernel: [ 318.195974] futex_wake_op: futex tries to shift op by -518; fix this program Jun 22 11:36:49 tack kernel: [ 318.195977] futex_wake_op: futex tries to shift op by -1; fix this program Jun 22 11:36:49 tack kernel: [ 318.195979] futex_wake_op: futex tries to shift op by -1; fix this program Jun 22 11:36:49 tack kernel: [ 318.199661] futex_wake_op: futex tries to shift op by -849; fix this program Jun 22 11:36:49 tack kernel: [ 318.199674] futex_wake_op: futex tries to shift op by -849; fix this program Jun 22 11:36:49 tack kernel: [ 318.199917] futex_wake_op: futex tries to shift op by -518; fix this program Jun 22 11:36:49 tack kernel: [ 318.199982] futex_wake_op: futex tries to shift op by -518; fix this program Jun 22 11:36:49 tack kernel: [ 318.398755] L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-gui de/hw-vuln/l1tf.html for details. Jun 22 11:36:49 tack kernel: [ 318.587324] WARNING: CPU: 2 PID: 32174 at mm/page_alloc.c:4385 __alloc_pages_nodemask+0x241/0x2b0 Jun 22 11:36:49 tack kernel: [ 318.587326] Modules linked in: acpi_call(OE) ipt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter nft_chain_nat_ipv4 nf_ nat_ipv4 xt_addrtype nft_compat xt_conntrack nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp overlay devlink cpufreq_userspace cpufreq_conser vative cpufreq_powersave ipmi_devintf ipmi_msghandler nf_tables nfnetlink appletalk psnap llc ax25 pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) cmac bnep fuse binfmt_misc pktcdvd snd_hda_codec_hdmi btusb btrtl btbcm btintel bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_hd a_codec_realtek snd_hda_codec_generic videodev media drbg ansi_cprng ecdh_generic nls_ascii nls_cp437 vfat fat arc4 intel_rapl snd_soc_skl msr snd_soc_skl_ipc snd_soc_ sst_ipc Jun 22 11:36:49 tack kernel: [ 318.587344] snd_soc_sst_dsp x86_pkg_temp_thermal intel_powerclamp snd_hda_ext_core coretemp snd_soc_acpi_intel_match iwlmvm snd_soc_ac pi kvm_intel snd_soc_core mac80211 snd_compress wmi_bmof i915 snd_hda_intel iwlwifi kvm snd_hda_codec snd_h da_core irqbypass snd_hwdep evdev intel_cstate joydev snd_pcm_oss drm_kms_helper intel_uncore serio_raw intel_rapl_perf mei_me snd_mixer_oss cfg80211 sg efi_pstore drm pcspkr mei efivars snd_pcm ucsi_acpi snd_timer typec_ucsi i2c_algo_bit iTCO_wdt iTCO_vendor_support intel_pch_thermal typec thinkpad_acpi tpm_crb wmi nvram snd soundcore tpm_tis rfkill video tpm_tis_core battery pcc_cpufreq ac tpm rng_core acpi_pad button parport_pc nfsd ppdev auth_rpcgss lp nfs_acl lockd grace sunrpc parport efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic Jun 22 11:36:49 tack kernel: [ 318.587362] fscrypto ecb btrfs zstd_decompress zstd_compress xxhash algif_skcipher af_alg sr_mod cdrom uas usb_storage dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear md_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci aesni_intel libahci aes_x86_64 crypto_simd libata cryptd xhci_pci glue_helper xhci_hcd e1000e psmouse scsi_mod usbcore i2c_i801 thermal usb_common Jun 22 11:36:49 tack kernel: [ 318.587375] CPU: 2 PID: 32174 Comm: keyctl Tainted: G OE 4.19.0-9-amd64 #1 Debian 4.19.118-2+deb10u1 Jun 22 11:36:49 tack kernel: [ 318.587376] Hardware name: LENOVO 20HD000EUK/20HD000EUK, BIOS N1QET67W (1.42 ) 10/03/2017 Jun 22 11:36:49 tack kernel: [ 318.587377] RIP: 0010:__alloc_pages_nodemask+0x241/0x2b0 Jun 22 11:36:49 tack kernel: [ 318.587379] Code: 89 f7 89 ee 45 31 f6 e8 4d d5 ff ff e9 fb fe ff ff e8 73 ae 01 00 e9 cb
Bug#944546: linux-source: Require build and include Hisilicon Hibmc drm driver in the installer
Hi! On Tue, Nov 12, 2019 at 12:32:09AM +0800, She Kairui wrote: >Package: linux-source >Version: 4.19.0-6 >Severity: important > >I'm trying to install Debian buster on to the Huawei Kunpeng arm64 server, >found that the installation graphic output not show up via the server BMC >virtual console. > >Huawei Kunpeng arm64 server using a hibmc chip on the mainboard, the lspci >output of the VGA device is: > > ~$ lspci -nn | grep VGA > 05:00.0 VGA compatible controller [0300]: Huawei Technologies Co., Ltd. >Hi1710 [iBMC Intelligent Management system chip w/VGA support] [19e5:1711] (rev >01) > >Currently the kernel VGA driver module (hibmc_drm.ko) was not included in the >netboot initrd (http://ftp.debian.org/debian/dists/stable/main/installer-arm64/ >20190702+deb10u1/images/netboot/netboot.tar.gz) . > >I have verified the BMC virtual console graphic output works well after adding >the hibmc_drm.ko into the netboot initrd, could you please help to built and >include this driver module in the installer? I've just added a merge request for this: https://salsa.debian.org/kernel-team/linux/merge_requests/209 I'll add another MR for the "sid" branch in a moment. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Bug#935318: Network interfaces not working in d-i on HiSilicon D05
Source: linux Version: 4.19.37-5+deb10u2 Severity: normal Hi! Trying to run the buster (10.0.0) installer via netboot on an arm64 server (HiSilicon D05), the machine boots the installer OK using PXE (so we definitely have the interfaces connected and working!). However, later on netcfg can't find a carrier on any of the network interfaces. I'm going to dig into this further and see if I can make any progress to see what's up. For reference, Ubuntu 18.04.01 seems to work fine on the same hardware (kernel 4.15.0-58). Cheers, Steve McIntyre IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Bug#930554: Please add support for Huawei's TaiShan server platform
On Sat, Jun 15, 2019 at 01:19:08PM +0100, Steve McIntyre wrote: >Source: linux >Version: 4.19.28-2 >Severity: important > >Hi folks, > >The TaiShan is an arm64 server made by Huawei, using the HiSilicon >1620 CPU. It's a nice big beast of a machine, with lots of cores, >memory etc. We've been loaned one to use (maybe as a buildd?), but at >the moment the Buster kernel doesn't support it out of the box. > >I'm partway through a set of patches to enable it, turning on some >device drivers and backporting a few fixes. Patch coming very soon. It >would be very helpful to have this in our Buster release. MR submitted: https://salsa.debian.org/kernel-team/linux/merge_requests/151 -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Bug#930554: Please add support for Huawei's TaiShan server platform
Source: linux Version: 4.19.28-2 Severity: important Hi folks, The TaiShan is an arm64 server made by Huawei, using the HiSilicon 1620 CPU. It's a nice big beast of a machine, with lots of cores, memory etc. We've been loaned one to use (maybe as a buildd?), but at the moment the Buster kernel doesn't support it out of the box. I'm partway through a set of patches to enable it, turning on some device drivers and backporting a few fixes. Patch coming very soon. It would be very helpful to have this in our Buster release. Cheers, Steve -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Missing virtio/scsi modules for arm64?
On Sat, Apr 27, 2019 at 12:39:31AM +0100, Steve McIntyre wrote: >On Sat, Apr 27, 2019 at 12:07:05AM +0100, Ben Hutchings wrote: >>On Fri, 2019-04-26 at 22:40 +0100, Steve McIntyre wrote: >>[...] >>> Hmmm, looking at my local mirror, I think there's another problem >>> then. I don't see scsi-modules-4.19* for arm64. Looks like we're >>> missing kernel config for arm64 here. Could you add that too please? >>[...] >> >>We are building it, but remember that it's built from the >>linux-signed-arm64 source package now. > >Gah, of course! I'd forgotten that. :-) Build testing locally suggests this does fix the problem, so I've pushed that change (and a similar one for armhf). Thanks Ben! -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Missing virtio/scsi modules for arm64?
On Sat, Apr 27, 2019 at 12:07:05AM +0100, Ben Hutchings wrote: >On Fri, 2019-04-26 at 22:40 +0100, Steve McIntyre wrote: >[...] >> Hmmm, looking at my local mirror, I think there's another problem >> then. I don't see scsi-modules-4.19* for arm64. Looks like we're >> missing kernel config for arm64 here. Could you add that too please? >[...] > >We are building it, but remember that it's built from the >linux-signed-arm64 source package now. Gah, of course! I'd forgotten that. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: Missing virtio/scsi modules for arm64?
On Fri, Apr 26, 2019 at 07:00:39PM +0100, Ben Hutchings wrote:
>On Fri, 2019-04-26 at 02:17 +0100, Steve McIntyre wrote:
>> Hey folks,
>>
>> I;m just trying to do a buster install of arm64 (using buster d-i RC1)
>> in a qemu VM, and it's failing to find the virtio cdrom. Checking into
>> this, it looks like we're missing some modules in the installer
>> environment.
>[...]
>> commit 5b3bcf67a7d8ba7745612a449cede24afeb97015
>> Author: Ben Hutchings
>> Date: Tue Feb 12 21:18:40 2019 +
>>
>> build/pkg-lists: Make {hyperv,virtio}-modules packages optional
>>
>> I intend to remove these udebs in a later upload of linux, moving
>> the drivers into per-driver-class packages.
>>
>> and I'm guessing these changes are related to what I'm seeing. Can you
>> suggest what we should be doing to fix things up, please? I'm at a
>> total loss to see where amd64 is gettting d-i modules from nowadays,
>> and arm64 should be reasonably similar in terms of things like block
>> device support modules here.
>
>For amd64 CD-ROMs, the package list for CD-ROMs is split between
>build/pkg-lists/cdrom/amd64.cfg and
>build/pkg-lists/cdrom/isolinux/amd64.cfg. The latter is where, for
>example, ata-modules is listed.
>
>In general, installer builds that include(d) virtio-modules, and aren't
>meant for netboot, should include scsi-modules. (scsi-{common,extra}-
>modules are also mentioned in some lists, but they no longer exist.)
Cool, thanks.
>I think this patch will fix arm64:
>
>--- a/build/pkg-lists/cdrom/arm64.cfg
>+++ b/build/pkg-lists/cdrom/arm64.cfg
>@@ -13,6 +13,8 @@ virtio-modules-${kernel:Version} ?
> usb-storage-modules-${kernel:Version}
> # USB and firewire cdroms both need this.
> scsi-core-modules-${kernel:Version}
>+# Support for SCSI cdroms.
>+scsi-modules-${kernel:Version}
> # Real ATA hardware needs this.
> sata-modules-${kernel:Version}
>
>--- END ---
Hmmm, looking at my local mirror, I think there's another problem
then. I don't see scsi-modules-4.19* for arm64. Looks like we're
missing kernel config for arm64 here. Could you add that too please?
>There are two other lists that look like they might be for netboot-ish
>builds, but I'm not sure:
>
>build/pkg-lists/generic/s390.cfg
>build/pkg-lists/generic/s390x.cfg
Pass - I know ~nothing about s390/x.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt
Missing virtio/scsi modules for arm64?
Hey folks,
I;m just trying to do a buster install of arm64 (using buster d-i RC1)
in a qemu VM, and it's failing to find the virtio cdrom. Checking into
this, it looks like we're missing some modules in the installer
environment. Going back to alpha 5 (kernel 4.19.12-1), we get the
following modules loaded:
Module Size Used by
efivars20480 0
nls_utf8 16384 1
isofs 49152 1
sr_mod 32768 1
cdrom 61440 1 sr_mod
virtio_scsi20480 1
scsi_mod 233472 2 virtio_scsi,sr_mod
virtio_net 49152 0
virtio_blk 20480 0
net_failover 20480 1 virtio_net
failover 16384 1 net_failover
gpio_keys 20480 0
virtio_pci 28672 0
virtio_mmio20480 0
virtio_ring28672 5
virtio_mmio,virtio_scsi,virtio_pci,virtio_blk,virtio_net
virtio 16384 5
virtio_mmio,virtio_scsi,virtio_pci,virtio_blk,virtio_net
In RC1 (4.19.28-2), we only get:
Module Size Used by
gpio_keys 20480 0
virtio_pci 28672 0
virtio_mmio20480 0
virtio_ring28672 2 virtio_mmio,virtio_pci
virtio 16384 2 virtio_mmio,virtio_pci
and if I look for things like virtio_scsi or sr_mod they're just not
in the initramfs any more which will explain what's going on. Ben, I
can see that in d-i you've changed the package lists recently (i.e. in
between the 2 d-i releases):
commit 5b3bcf67a7d8ba7745612a449cede24afeb97015
Author: Ben Hutchings
Date: Tue Feb 12 21:18:40 2019 +
build/pkg-lists: Make {hyperv,virtio}-modules packages optional
I intend to remove these udebs in a later upload of linux, moving
the drivers into per-driver-class packages.
and I'm guessing these changes are related to what I'm seeing. Can you
suggest what we should be doing to fix things up, please? I'm at a
total loss to see where amd64 is gettting d-i modules from nowadays,
and arm64 should be reasonably similar in terms of things like block
device support modules here.
Cheers,
Steve
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Bug#922478: have yet to find an armhf board that works with 4.9.144-3
On Mon, Feb 18, 2019 at 05:09:12PM +0100, Cyril Brulebois wrote: >Control: tag -1 patch > >Adrian Bunk (2019-02-17): >> On Sun, Feb 17, 2019 at 09:52:48AM -0800, Vagrant Cascadian wrote: >> > After upgrading to the latest 4.9.x kernel in sid, all of the armhf >> > boards running this kernel failed to boot. >> > >> > Adding to the list: >> > >> > imx6: Cubox-i4pro, Cubox-i4x4, Wandboard Quad >> > exynos5: Odroid-XU4 >> > exynos4: Odroid-U3 >> > rk3328: firefly-rk3288 >> > sunxi A20: Cubietruck >> > >> > >> > So it clearly impacts a wide variety of systems... >> >> debian/patches/debian/arm-avoid-abi-change-in-4.9.139.patch changes >> the order of struct processor but lacks a corresponding change to >> arch/arm/mm/proc-macros.S > >Based on this suggestion and Julien's suggested patch on IRC a couple >hours ago, I've tested the attached patch successfully (as in: from a >busy loop in qemu-system-arm to the “expected” kernel panic, as >discussed in another subthread). > >I've uploaded linux-image binaries (armmp and armmp-lpae) here, which >were cross-built through sbuild, thanks to Vagrant's suggestion on IRC: > https://people.debian.org/~kibi/linux-bug-922478/ > >which is: > DEBIAN_KERNEL_DISABLE_DEBUG=yes sbuild -d stretch-proposed-updates -c > stretch-amd64-sbuild --build=amd64 --profiles='pkg.linux.notools nodoc > nopython cross pkg.linux.nosource' --host=armhf linux_4.9.144-4.dsc > >Checking this on real hardware would be great, trying to put everyone >involved in the loop through cc. > > >Cheers, >-- >Cyril Brulebois (k...@debian.org)<https://debamax.com/> >D-I release manager -- Release team member -- Freelance Consultant >From 07f237b3911a685b18a7584456ace1293636bcc7 Mon Sep 17 00:00:00 2001 >From: Cyril Brulebois >Date: Mon, 18 Feb 2019 13:49:50 +0100 >Subject: [PATCH] Update debian/arm-avoid-abi-change-in-4.9.139.patch (Closes: > #922478). > >This makes it take into account the function pointers reordering in >arch/arm/mm/proc-macros.S (addition of check_bugs), fixing the failure >to boot many armhf devices. > >With thanks to Adrian Bunk for the hint, and Julien Cristau for the >prospective patch. ... Just to confirm: installed this on the Armada XP on my desk (copy of the buildd hardware we're using) and it works just fine. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders Bananapi and Lamobo R1 unbootable
On Mon, Feb 18, 2019 at 11:28:10AM +, Neil Williams wrote: >On Sun, 17 Feb 2019 21:26:41 +0100 (CET) "Timo Sigurdsson" >> >> So, I also tested 4.9.135-1 on a Bananapi board and can confirm it >> works. >> >> I would suspect the issue is caused by Debian's kernel configuration >> or changes. The Kernel CI project has ARM hardware, including the >> Bananapi board and does tests of stable kernel updates to verify that >> the kernel boots. At least with multi_v7_defconfig and >> sunxi_defconfig, upstream 4.9.144 does boot on Allwinner-based >> hardware, see: >> https://kernelci.org/soc/allwinner/job/stable-rc/kernel/v4.9.144/ Yup. The bug is clearly coming from a local Debian patch. >Is it feasible to have a script in devscripts or similar which maps the >version of the kernel *Candidate* to KernelCI URLs for the same >version? > >Can we correlate Debian kernel versions to something like >https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.144/ >or >https://kernelci.org/boot/all/job/stable-rc/kernel/v4.9.144/ ? Sure, maybe. I've suggested kernelci as a useful thing to help here, but we really need to be testing kernels complete with all the Debian patches to... -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders many systems unbootable
On Sun, Feb 17, 2019 at 04:54:00PM -0800, Vagrant Cascadian wrote: >On 2019-02-17, Vagrant Cascadian wrote: >> On 2019-02-17, Timo Sigurdsson wrote: >>> Cyril Brulebois schrieb am 17.02.2019 19:38: >>>> Jürgen Löb (2019-02-16): >> FWIW, I also built a local package from 4.9.155-1~ from salsa/stretch >> git, and it worked on a wandboard quad. >> >> $ uname -a >> Linux wbq0 4.9.0-9-armmp #1 SMP Debian 4.9.155-1~20190217~1 (2019-02-17) >> armv7l GNU/Linux > >That seemed to work fine on several tested boards. > >I also did a local build commenting out >"debian/arm-avoid-abi-change-in-4.9.139.patch" in debian/patches and >removing "debian/abi/4.9.0-8/armhf_none_armmp" so that the abi conflicts >didn't fail to build... > >$ uname -a >Linux cbxi4b 4.9.0-8-armmp #1 SMP Debian 4.9.144-4~20190217~1 (2019-02-17) >armv7l GNU/Linux Yes, me too. Built similar and tested on the Marvell Armada XP here and it solved the problem. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Bug#904385: arm64: sigaltstack fails with MINSIGSTKSZ for 32-bit processes
On Wed, Jul 25, 2018 at 04:25:03PM +0100, Steve McIntyre wrote: >On Mon, Jul 23, 2018 at 09:40:33PM +0200, Aurelien Jarno wrote: >>control: affects -1 glibc >>control: found linux/4.17.6-2 >> >>On 2018-07-23 21:31, Aurelien Jarno wrote: >>> Package: src:linux >>> Version: 4.9.110-1 >>> Severity: normal >>> >>> Dear Maintainer, >>> >>> The arm64 kernel allows one to run aarch32 processes on an aarch64 >>> processor (if it has support for it), using the standard 32/64-bit >>> syscall compatibility. However this compat layer does not correctly >>> validate the arguments of the sigaltstack syscall. >>> >> >>I forgot to say that the problem is reproducible with kernel 4.17.6. > >Fix proposed in https://lkml.org/lkml/2018/7/25/409 At Will's suggestion, I've just tested that patchset locally and it definitely fixes this problem so I've added a Tested-by: for him. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: Status and open questions for debian-installer with backports support
On Mon, Aug 13, 2018 at 01:44:48PM +0200, Julien Cristau wrote: >On 08/13/2018 01:57 AM, Steve McIntyre wrote: >> On Thu, Aug 02, 2018 at 10:56:59AM +0200, Cyril Brulebois wrote: >>> => Question: should we restrict architectures we build images for? >> >> Probably. I'm only thinking x86, arm64 and maybe armhf. Wait for >> people to ask for others and add on a case-by-case basis. >> >I'd even suggest s/x86/amd64/ > >New 32-bit x86 hardware shouldn't be a huge use case nowadays. That's a fair point, yes. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Status and open questions for debian-installer with backports support
gt; Question: how to ensure firmwares from backports are available in d-i > and in the installed system? > >Finally, what architectures are we supporting? I can't speak for >debian-cd, but at least for the d-i part, we'll likely fork master into >stretch-backports and merge there. So we should keep track of any arch- >specific changes and debian-installer is likely to be buildable/built on >all architectures for no extra cost. If there are other bits that users >need to rely on, like flash-kernel and other components, I think they >should just consider installing testing instead. We can't reasonably be >expected to backport all the things. Sure. >=> Question: should we restrict architectures we build images for? Probably. I'm only thinking x86, arm64 and maybe armhf. Wait for people to ask for others and add on a case-by-case basis. >Last question: how often do we produce such an image? I don't think it's >reasonable to do that every time a new major version of linux is made >available in the backports repository. Doing that once around the middle >of the release cycle would look good to me. This would kind of mimic the >“and a half” thing we had in the past. Once we get the process right, we >might think about doing so another time or two, but we already have limited >humanpower to deal with stable point releases and alphas for testing >(at least oldstable is gone now)… > >=> Question: what to advertise/communicate on? One-shot only is probably > a good rule of thumb? Let's try to do one first, and then work out what to do if it succeeds. :-) In the long run, I'm thinking I'd like to do a smallish number in the lifetime of a stable release. Maybe (roughly!) following the point release schedule? Every 2-3 months? >What to do with modified components >=== > >My current approach would be to get net-retriever, apt-setup, and >base-installer (once this last one is ready of course) updated in >stable. This would greatly help building, testing, and running >debian-installer without having to special-case everything in various >places. Of course this is subject to a green light from the release >team, but I might be trusted to get things right (and/or to get the >pieces working again if anything breaks). Nod. >We would be able to rely on their having built-in support for backports >(remember, it's only enabled when a specific file is present). We could >then just upload src:debian-installer to stretch-backports (after dak's >been patched to allow that), and point debian-cd to the resulting >images. Sounds cool. I'll probably need to tweak on my end for that to work, but it should be straighforward. In terms of *my* code changes for debian-cd, all the changes so far are already in stable (not that it matters all that much). So long as the changes are not too intrusive, I'll also be taking any changes onto the buildd/stretch branch too. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Bug#904385: arm64: sigaltstack fails with MINSIGSTKSZ for 32-bit processes
On Mon, Jul 23, 2018 at 09:40:33PM +0200, Aurelien Jarno wrote: >control: affects -1 glibc >control: found linux/4.17.6-2 > >On 2018-07-23 21:31, Aurelien Jarno wrote: >> Package: src:linux >> Version: 4.9.110-1 >> Severity: normal >> >> Dear Maintainer, >> >> The arm64 kernel allows one to run aarch32 processes on an aarch64 >> processor (if it has support for it), using the standard 32/64-bit >> syscall compatibility. However this compat layer does not correctly >> validate the arguments of the sigaltstack syscall. >> > >I forgot to say that the problem is reproducible with kernel 4.17.6. Fix proposed in https://lkml.org/lkml/2018/7/25/409 -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Re: Scheduling 9.5
On Tue, Jun 12, 2018 at 12:44:52PM +0100, Adam Barratt wrote: >On 2018-06-08 18:51, Adam D. Barratt wrote: > >Given all of the above, I think the sanest option is to concentrate on >getting 8.11 done and jessie off our radar and then get 9.5 sorted. > >For suggested dates for 9.5, we know that June 30th is a no-go, Debcamp >starts on July 21st and then Debconf on the 28th. So that leaves us with: > >- July 7th >- July 14th > >Are people available for either or both of those dates? Both look good for me, yup. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Scheduling 9.5
On Fri, Jun 08, 2018 at 06:51:18PM +0100, Adam Barratt wrote: >[Cc += debian-kernel] > >On Sun, 2018-05-20 at 12:04 +0200, Joerg Jaspert wrote: >> On 15037 March 1977, Jonathan Wiltshire wrote: >> > - May 26th (meaning freeze this coming weekend, which might be a >> > big >> > ask) >> >> No. >> >> > - Jun 2nd (which may require an unusual SRM) >> >> Possible. >> >> > - Jun 9th (getting quite a way out of cadence, but maybe that >> > can't be >> > helped) >> >> Possible. > >We're past any of the above by now, and while looking through the to-do >list for the final jessie point release, I noticed that we currently >have some packages in opu with versions higher than stable. > >We can either accept the packages and put up with the situation for a >short while, or do 9.5 before 8.11. In practical terms, that would >likely mean both 9.5 and 8.11 on June 23rd, freezing both next weekend. >How do people feel about that? That works ok for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Bug#896775: Acknowledgement ([PATCH] Backport support for Qualcomm Centriq onboard emac NIC)
On Mon, Apr 30, 2018 at 12:21:28PM +0100, Steve McIntyre wrote: >I've also added a backport for the one erratum that's known about for >Falkor v2 CPUs (E1041). Other Qualcomm errata code is in upstream, but >the other snippets are for v1 which is not widely available so >probably not worth backporting. > >I've added an MR on salsa for both of these, at > > https://salsa.debian.org/kernel-team/linux/merge_requests/8 > >Please shout if you need me to do anything more. Now updated after Ben's feedback: https://salsa.debian.org/kernel-team/linux/merge_requests/11 -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Bug#896775: Acknowledgement ([PATCH] Backport support for Qualcomm Centriq onboard emac NIC)
I've also added a backport for the one erratum that's known about for Falkor v2 CPUs (E1041). Other Qualcomm errata code is in upstream, but the other snippets are for v1 which is not widely available so probably not worth backporting. I've added an MR on salsa for both of these, at https://salsa.debian.org/kernel-team/linux/merge_requests/8 Please shout if you need me to do anything more. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Bug#896775: [PATCH] Backport support for Qualcomm Centriq onboard emac NIC
Source: linux Version: 4.9.82-1+deb9u3 Severity: normal Tags: patch Hey folks, I've backported support for the onboard network interface on the Qualcomm Centriq arm64 server platform, mostly straight cherry-picks from upstream 4.15. Please apply the patch to add this support for the next Stretch point release. Cheers, Steve linux_4.9.82-1+deb9u3+nmu1.debdiff.xz Description: application/xz
Re: UPDATE: Re: Proposal: UEFI secure boot implementation sprint, 5-8 April 2018
On Sun, Jan 28, 2018 at 11:46:10AM +, Steve McIntyre wrote: > >HOWEVER... those dates clash with another group already booked in at >the LinuxHotel in Essen. So we've started talking to people in Fulsa >as a fallback option. We have a tentative space for a venue and now we >need to book hotel rooms. So... If you're *definitely* planning on >coming for the sprint (Fulda, Germany, 5-8 April) please reply to this >mail to confirm in the next few days and we will organise. Now is a >good time to book travel. > >I'll start by saying "yes, I'm definitely coming". > >(Deliberately CCing all 9 people in the Doodle poll). After a week, we've only had 4 people confirm that they're coming. Please respond so we can organise properly. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Bug#886782: pulseaudio: Audio playback is slow (sample rate mismatch?)
On Sat, Feb 03, 2018 at 05:41:34PM +, Andy Simpkins wrote: > >Many thanks for your help and suggestions, this is now sounding like >a driver issue. We'll re-assign this to the appropriate linux-image >package I'm using and CC the kernel folks too. > >Dear kernel folks - sorry, looks like this is your bug (and clearly upstream!). Quickly responding here again - we've just tried the latest kernel from experimental (4.15.0-rc8) and this still shows the same problem. -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
UPDATE: Re: Proposal: UEFI secure boot implementation sprint, 5-8 April 2018
On Sun, Jan 21, 2018 at 05:49:20PM +, Steve McIntyre wrote: > >We have 7 people with dates in the poll so far: > > Helen Koike > Luke Faraone > Me > Ben Hutchings > Tollef Fog Heen > Chris Lamb > Philipp Hahn > >Any more people interested in coming? If so, please fill in the dates >ASAP. I was hoping for more ftpmaster folks and a buildd maintainer, >if at all possible. We now have *9* people who have registered their preferences for a F2F meeting in the Doodle poll, and a couple more who will try to join us remotely. It's reasonably clear that the best dates for us are 5-8 April, so let's go with that. HOWEVER... those dates clash with another group already booked in at the LinuxHotel in Essen. So we've started talking to people in Fulsa as a fallback option. We have a tentative space for a venue and now we need to book hotel rooms. So... If you're *definitely* planning on coming for the sprint (Fulda, Germany, 5-8 April) please reply to this mail to confirm in the next few days and we will organise. Now is a good time to book travel. I'll start by saying "yes, I'm definitely coming". (Deliberately CCing all 9 people in the Doodle poll). -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Proposal: UEFI secure boot implementation sprint, early 2018
On Mon, Jan 22, 2018 at 02:42:41AM +0530, Chris Lamb wrote: >Hi Steve, > >> We have 7 people with dates in the poll so far: > >I wrote it in the poll form so perhaps repeating in this context; I'm only >listed as a "backup" of sorts! ACK, I saw that. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Re: Proposal: UEFI secure boot implementation sprint, early 2018
On Mon, Jan 15, 2018 at 05:42:24PM +, Steve McIntyre wrote: > >Hey Helen! Thanks for picking this up. Apologies for me going dark >about this. I had a torrid time of things in December with a family >bereavement, and this was one of many things that I had to drop >temporarily. > >Now it's time to get things going again. Helen has suggested March >1-4, but we're not 100% sure if that works for everyone who should be >at the sprint. Let's work out this out quickly with a Doodle >poll. Helen has created one at > > https://doodle.com/poll/p2sbgmvnd65vaup8 > >(I've added a link in the wiki page too). Please fill in there the >dates that you can make and we'll get organised. We have 7 people with dates in the poll so far: Helen Koike Luke Faraone Me Ben Hutchings Tollef Fog Heen Chris Lamb Philipp Hahn Any more people interested in coming? If so, please fill in the dates ASAP. I was hoping for more ftpmaster folks and a buildd maintainer, if at all possible. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Proposal: UEFI secure boot implementation sprint, early 2018
On Fri, Jan 12, 2018 at 04:29:22PM -0200, Helen Koike wrote: > >Linux Hotel is available on March 1-4, and we have setup a wiki to add all >the information. > >https://wiki.debian.org/Sprints/2018/SecureBootSprint > >Could you please add yourselves in the list so we can better estimate the >number of people going and the costs? Hey Helen! Thanks for picking this up. Apologies for me going dark about this. I had a torrid time of things in December with a family bereavement, and this was one of many things that I had to drop temporarily. Now it's time to get things going again. Helen has suggested March 1-4, but we're not 100% sure if that works for everyone who should be at the sprint. Let's work out this out quickly with a Doodle poll. Helen has created one at https://doodle.com/poll/p2sbgmvnd65vaup8 (I've added a link in the wiki page too). Please fill in there the dates that you can make and we'll get organised. Cheers, -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Proposal: UEFI secure boot implementation sprint, early 2018
[ Mailing various interested folks directly, and adding a CC to the relevant lists and the DPL. If you think I've missed people off, please let me know - my intention is not to slight anybody here. ] Hi folks, We've had more discussion over the last few days about how we could/should implement UEFI Secure Boot infrastructure in Debian [1-4]. I hope that we've got past the "should we do this or not" diversions. It's time that we got together to finish the discussion and get things up and running. We've had several proposed routes to make the infrastructure work: * "byhand" or similar, driving things from ftpmaster getting the package maintainer do the work to combine unsigned binaries with sigs then upload again * "dh_sign", driving things from the maintainer scripts running on buildds, uploading automatically to the archive * a hybrid of these: driving things from buildd, but returning the sigs to the maintainer (somehow) to combine and upload There are pros and cons and for all routes, but I believe that it should be possible to work together to design something that will do what we need without triggering too many objections or security fears. Sprint proposal === I propose that the interested people get together for a sprint *in early 2018*. We should have the following people to *agree a design* and *implement* that design: * (at least one) DSA member, able to do sysadmin-level things needed. Tollef and Julien have already been working in this area and understand what we're trying to do. * (at least one) ftpmaster, able to implement and/or review any needed changes in dak. Ansgar, Joerg and Luk have been involved in discussions already and understand the problem space. * (at least one) buildd software maintainer, able to implement and/or review any needed changes in the buildd stack. * maintainers of the packages that we expect to use the infrastructure (Linux kernel, grub, fwupdate), so we can work through example uploads and test things. Ben obviously covers the kernel side, and I have access for the grub and fwupdate packages. * Helen has been the primary developer working in this area so far, providing code for two of the proposals so far and helping to drive discussion. She should be there! I expect that 3-4 days together should be enough for us to make this work. To be honest, I'd hope that 2 day might be enough for what we need, but 3-4 days should give us sufficient time to experiment and play with things. We don't *have* to have everybody together physically in one place, but experience tells me that would be by far the most effective and efficient way to do things. So... Please respond with: = a) your willingness to take part in this sprint b) your availability to travel for this sprint c) ideas on when/where we could meet up, if you have any = and we'll get something sorted out. My own preferences would be to try and arrange something in January (maybe) in Europe (as most of the people are in Europe!), but those are not hard and fast. Maybe Germany to make it easier for Joerg/Ansgar to join us? If we don't have this done by the end of March, I don't think we'll ever get Secure Boot in Debian. @lamby: adding you in CC early for sprint budget approval. Clearer details to follow! [1] https://wiki.debian.org/SecureBoot#Wrap-up_of_the_discussions_so_far [2] https://lists.debian.org/debian-efi/2017/10/msg00029.html [3] https://lists.debian.org/debian-efi/2017/11/msg7.html [4] https://lists.debian.org/debian-efi/2017/11/msg8.html -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves. signature.asc Description: PGP signature
Re: Secure boot signing infrastructure - feedback request
On Wed, Nov 22, 2017 at 11:11:02PM +, Ben Hutchings wrote: >On Wed, 2017-11-15 at 11:18 -0200, Helen Koike wrote: >[...] >> I think a Sprint about Secure Boot would be great, we just need to make >> sure that at least the people who disagree with one approach or the >> other will be present. >> @ftpmasters and @Ben, if you could reply if you would be willing to >> attend it would be great, so we can start organizing it and work >> together to find a good solution. > >I am willing to attend and work on this if we can agree on the >direction beforehand. Cool. -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Secure boot signing infrastructure - feedback request
On Wed, Nov 22, 2017 at 11:07:02PM +, Ben Hutchings wrote: >On Wed, 2017-10-11 at 21:48 -0300, Helen Koike wrote: >[...] >> I did a summary about the current discussion here: >> https://wiki.debian.org/SecureBoot#Wrap-up_of_the_discussions_so_far >> Feel free to edit this wiki or let me know if I forgot something. >> >> Questions: >> * About item 2.1. (reproducible builds), if we strip the signatures from >> the binaries before doing the comparison is the reproducible build >> criteria acceptable? Can we just strip the signatures and if the result >> is the same we consider it reproducible? Or is changing the criteria ok? > >The Reproducible Builds project has consistently set the standard that >results must be bit-for-bit identical. I don't think we should expect >it to add an exception that requires parsing archives and executables >to verify that they're "mostly reproducible". So there are always going to be things that *can't* be reproducible then. Anything with signatures directly applied is fundamentally incompatible with that standard. Meh, I'm not going to lose any sleep over it. ... >> * Item 2.4 seems the strongest argument to me against the buildd >> approach, but the byhand approach seems to complicated, or we need to >> reformulate it, any suggestions? > >I think that it should be possible to mitigate these problems by >combining the proposed signing service with the earlier plan of doing >two source uploads: > >Firstly, the signing service would not provide the signatures in plain >text but would encrypt them using a developer's GPG key (or multiple >keys). Key selection might be done by specifying the key fingerprint >in the source package (which could be problematic for binNMUs), or in >the signing service configuration (which would effectively prevent >source NMUs). This makes the signing service useless to an attacker >who only compromises a buildd briefly. OK, that sounds like a more useful compromise. >Secondly, the detached signatures would be uploaded as an extra package >to a separate archive suite, similar to the way debug symbol packages >are now handled. Those extra packages could easily be ignored when >attempting to reproduce the build. But I don't know whether dak's >logic for debug symbol suites is sufficiently general to handle this. Pass. Ansgar? -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: Secure boot signing infrastructure - feedback request
Nearly three weeks later with no responses. Let's see if we get things moving... On Wed, Oct 11, 2017 at 09:48:46PM -0300, Helen Koike wrote: > >I did a summary about the current discussion here: >https://wiki.debian.org/SecureBoot#Wrap-up_of_the_discussions_so_far >Feel free to edit this wiki or let me know if I forgot something. I think it's a fair summary, yes. >Questions: >* About item 2.1. (reproducible builds), if we strip the signatures from >the binaries before doing the comparison is the reproducible build >criteria acceptable? Can we just strip the signatures and if the result >is the same we consider it reproducible? Or is changing the criteria ok? I *personally* believe that being able to remove the signatures and compare binaries is fine for reproducibility purposes. Arguments otherwise would help here. >* About item 2.2. Would it be ok if we just have a easy revoke mechanism? >In Shim there is already a MokListX (a blacklist of keys or binary >hashes), but the current way to update this list is if the user has >physical access to the machine, but I was talking with the Shim upstream >maintainer and we agreed that we could implement a solution where we >could feed a blacklist to shim, and if this list is signed by the >vendor_cert (aka Debian's key in our case), and if it is a newer version >of the list, shim would update MokListX without requiring user >intervention (it would be an equivalent to KEK for UEFI) ACK. >Is this solution acceptable? If we have an easy way to revoke, then we >can easily undo an attacker's work. We can sign everything automatically >(if the package is in a whitelist) without the need for the ftp masters >to review each upload manually. Right. Wanting to go the revocation route would depend on the development of yet more new software features. But: this is not something that any of the other SB-supporting distros seem to be caring about so far so I don't think it's something we should have to implement as a pre-requisite. >* Item 2.4 seems the strongest argument to me against the buildd >approach, but the byhand approach seems to complicated, or we need to >reformulate it, any suggestions? We've been discussing Secure Boot for ~5 years now, and I think it's an important feature that we should support in Debian. Does anybody here disagree with that? Multiple people have spent time designing and implementing pieces of the solution to make it work in Debian's infrastructure, but we've yet to make any progress in actually *doing* it. We've had a suggestion (and initial patches) to do this via "autobyhand" scripts on ftp-master, but we've finally seen public objections to that design from ftpmaster. Ben's hopes for that route seem unrealistic too, in terms of manual processing and checking. As a second option, in a discussion with Joerg (remotely) and Luke at DebConf, we thrashed out what we thought was a reasonable alternate solution to drive signing via the buildds instead. Ben has voiced some concerns about the security of that path (extending the attack surface for signed binaries) and reproducibility. So, we're at an impasse. We've had multiple attempts to get this going, with various subsets of this group discussing designs but not *all* the interested parties at each point. We've seen (effective) vetos of each of those designs, meaning we're stalled. Where do we go from here? I appreciate that some folks might feel slighted that they've been left out of some of the discussions. If so, sorry - that was not intentional. :-( Can we put that behind us and work together to make a workable solution please? I propose a sprint to get things moving. I'm prepared to organise it, and facilitate as much as I can. I recognise that not everybody might be able to (or willing to) attend in person, but I don't think that should be a barrier to constructive discussions. Thoughts? -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed? signature.asc Description: PGP signature
Re: Secure boot signing infrastructure - feedback request
On Mon, Oct 09, 2017 at 07:00:14PM +0100, Ben Hutchings wrote: >On Mon, 2017-10-09 at 17:38 +0100, Steve McIntyre wrote: >> On Mon, Oct 09, 2017 at 02:01:15PM +0100, Ben Hutchings wrote: >[...] >> > It also appears to mean that buildds can get anything signed on demand >> > with no human intervention at all, without all the checks that dak does >> > on uploads. This seems to be to substantially raise the risk of >> > signing evil code and needing to revoke those signatures (or the >> > signing key). >> >> We spoke about this too. Source packages uploaded and eventually built >> on the buildds already go through dak and wanna-build, for one. We >> have to trust that mechanism already. > >It's also audited - every upload is publicly logged, which makes it >hard for an attacker to hide an evil upload. > >The archive is signed, rather than individual packages, and those >signatures are valid for a limited period. So if an evil upload is >successful, we can replace it, warn users, and then by the time it's >forgotten the signature will be invalid. > >A signing service would have to implement a separate audit mechanism. >And code signing can't be time limited so if we sign an evil upload >we'll need to revoke it somehow. Right, thanks for explaining. I understand your concerns much better now. >> What human intervention are you wanting here? > >A human decides when processing the BYHAND queue whether this binary >upload looks reasonable. If it's built from an NMU, I would hope this >gets extra scrutiny (perhaps including a query to the maintainer). >(Ideally that would happen at the source upload stage for packages that >get code-signed. I'm not sure if that's possible to do.) The plan for the ftpmaster route (as communicated to me) was *not* necessarily going to need actual manual processing of the BYHAND queue for bits needing signing. Is that something we can (should?) legitimately expect - every signed package to get extra manual checking by ftpteam? >Also, dak checks that every binary upload corresponds to a source >upload, so an evil upload will have to be either a source upload or a >replacement of a binary upload. It seems like the proposed signing >service would allow an attacker that compromises a buildd to get code >signed at any time, independently of a source upload. True, yes. The *normal* flow would also see output going through dak and validating the source-binary relationship, but a compromised buildd could of course sidestep that, by simply not uploading the results at all. On the flip side, how far are we going to get if we can't trust the buildds? Reproducibility helps, but only if the source uploader can already generate matching builds for all the packages on all the architectures we want to support. >> We're also looking at a whitelist of specific packages >> that the buildd and signing service will allow to be signed, to reduce >> the potential attack surface. > >This mechanism already exists in dak, of course. Nod. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Secure boot signing infrastructure - feedback request
On Mon, Oct 09, 2017 at 02:01:15PM +0100, Ben Hutchings wrote: >On Thu, 2017-10-05 at 14:57 -0300, Helen Koike wrote: >> Hello all, >> >> As you probably already know, Debian doesn't support the Secure Boot >> chain yet. >> To support it we need to sign Grub and the Kernel with our key, so we >> are discussing the best infrastructure for this workflow. >> >> The first approach we had was to add a by-hand script in Dak as >> described here >> https://wiki.debian.org/SecureBoot#First_option:_by-hand_script_in_dak >> But this option wasn't well received by the ftpteam > >I would like to know what the objection was. I'll let the ftpteam people expand on that. >> The second approach we have is to add some debhelper scripts (e.g >> dh_sign...) that will access a signing service which will sign the >> binaries with Debian's key. We would use the dh_sign... helpers when >> making an extra binary package. buildd would then publish the -signed >> version of the package in the archives. >> Please see a more detailed explanation here >> https://wiki.debian.org/SecureBoot#Second_option:_use_buildd_.2B-_debhelper_instead_of_dak >> A current known issue with this approach is the NEW queue: it requires >> the maintainer to also upload binaries for an architecture on first >> upload, and these binaries are not rebuilt by the buildd ( see >> https://wiki.debian.org/SecureBoot#Issues ). > >It also makes all these packages unreproducible, which is a policy >violation. Surely *anything* with a signature is going to be unreproducible directly, by definition. To check for reproducibility, you'll need to strip the signatures. Or are you claiming something else? There's two ways to solve this, that we came up with in discussion: * the dh_sign helpers will be configurable on the building machine - they can be set up to use whatever key setup is desired. That could be local on the machine, or a remote signing service, or simply a no-sign pass-through mode. That last mode could validate the reproducibility. * include a tool to reproducibly just strip the signatures on binaries >It also appears to mean that buildds can get anything signed on demand >with no human intervention at all, without all the checks that dak does >on uploads. This seems to be to substantially raise the risk of >signing evil code and needing to revoke those signatures (or the >signing key). We spoke about this too. Source packages uploaded and eventually built on the buildds already go through dak and wanna-build, for one. We have to trust that mechanism already. What human intervention are you wanting here? We're also looking at a whitelist of specific packages that the buildd and signing service will allow to be signed, to reduce the potential attack surface. >Plus the reliability issues you pointed out on the wiki. Right - we're trying to consider the issues as we go. >> I would like to know everyone's opinions about these approaches, if you >> agree to go forward with the second approach described above and how do >> we solve the NEW queue policy issue. > >So far as I can see, the second approach is difficult, risky, >unreliable and leads to policy violations. > >On the other side... there is an FTP team objection with no documented >explanation. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Bug#874251: installation-reports: Debian 9.1 installer fails on HP ProLiant DL360 G4 with HP Smart Array 6i
On Mon, Sep 04, 2017 at 08:13:39PM +0200, rpr // wrote: >On 4 September 2017 at 16:50, Steve McIntyre <st...@einval.com> wrote: >>> >>>Is that something to be fixed on the kernel side? Or some buggy UEFI >>>that would need a workaround maybe? >> >> That's a good question. acpi=off is often a workaround for buggy >> firmware in my experience, but not typically something fixable >> externally. > >I can add to this report that some time ago I successfully installed >Debian 8.7.1 amd64 (kernel 3.16 without apci=off parameter) on the >same hardware. It seems to me this issue in Debian 9.1 installer is a >regression. Ah, OK. That's useful information. Sounds like it might be a kernel bug then... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: Bug#874251: installation-reports: Debian 9.1 installer fails on HP ProLiant DL360 G4 with HP Smart Array 6i
On Mon, Sep 04, 2017 at 04:23:25PM +0200, Cyril Brulebois wrote: >Hi, > >Adding kernel maintainers and debian-cd to the loop. > >rpr // <rpr.nos...@gmail.com> (2017-09-04): >> Package: installation-reports >> Severity: important >> >> -- Package-specific info: >> >> Boot method: USB flash drive >> Image version: >> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso >> (2017-07-22) >> Date: 2017-08-26 17:00 UTC >> >> Machine: HP ProLiant DL360 G4 with HP Smart Array 6i >> Partitions: >> >> >> Base System Installation Checklist: >> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it >> >> Initial boot: [E] >> Detect network card:[O] >> Configure network: [O] >> Detect CD: [O] >> Load installer modules: [O] >> Clock/timezone setup: [O] >> User/password setup:[O] >> Detect hard drives: [O] >> Partition hard drives: [O] >> Install base system:[O] >> Install tasks: [O] >> Install boot loader:[O] >> Overall install:[O] >> >> Comments/Problems: >> Booting installer with default options locks up after >> Loading /install.amd/vmlinuz... ok >> Loading /install.amd/initrd.gz... ok >> >> Booting in expert mode gives an error about "NMI watchdog: BUG: soft >> lockup" - see the screenshot in the attachment. >> >> Booting and running installer was successful after adding acpi=off >> kernel parameter. > >Is that something to be fixed on the kernel side? Or some buggy UEFI >that would need a workaround maybe? That's a good question. acpi=off is often a workaround for buggy firmware in my experience, but not typically something fixable externally. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Enhancement of unsupported adapters
On Fri, Jul 28, 2017 at 02:37:47PM +0200, Thomas Völker wrote: >Dear sirs, > >after a disaster with windows on my HP x2 10-k000ng was Debian my last hope >to avoid a hardware scrap. >So after installtion of Debian 9 i386 I can work at least offline. >Do you think it is possible to integrate the github fix for the realtek >adapter rtl8723bs with SDIO supporrt into the unsupported part of the debian >distribution? Hi Thomas, The Debian-CD list isn't the best place for this kind of request. You're better off talking to the kernel maintainers - see the CC above... -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone
Re: Bug#867898: debian-installer-netboot-images: debian-installer-9-netboot-amd64 scsi modules missing. Netboot image unusable
On Thu, Jul 13, 2017 at 01:09:58AM +0100, Steve McIntyre wrote: >On Thu, Jul 13, 2017 at 01:50:34AM +0200, Cyril Brulebois wrote: >> >>> But this package is also missing on the "release" DVDs for "amd64". >>> Nearly every other architecture has this package within an image >>> (whether "netinst" oder "DVD"). See >>> https://cdimage-search.debian.org/?search_area=release=simple=scsi-modules=Search&.cgifields=search_area&.cgifields=type >> >>Adding debian-cd@ accordingly. > >scsi-modules-* has been in the exclude-udebs list since forever... I >can remove that if desired? Not sure of exactly why this was added - >tracking back through debian-cd history now. In fact, I should have thought a little longer. It's in the exclude list as the cdrom version of the initramfs already has to include the SCSI modules, to be able to find the CD. We dropped the separate udebs to save space - no need for two copies on the CD. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: Bug#867898: debian-installer-netboot-images: debian-installer-9-netboot-amd64 scsi modules missing. Netboot image unusable
On Thu, Jul 13, 2017 at 01:50:34AM +0200, Cyril Brulebois wrote: >Paschedag, Robert <paschedag.netlut...@swr.de> (2017-07-12): >> thank you for your hints on the packages, that *are* available for >> amd64. The package we need is >> >> scsi-modules-4.9.0-3-amd64-di_4.9.30-2_amd64.udeb >> >> this one contains the needed modules for the LSI logic controller (and >> several other) >> >> ... >> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/ >> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/ >> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptbase.ko >> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptfc.ko >> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptsas.ko >> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptscsih.ko >> ./lib/modules/4.9.0-3-amd64/kernel/drivers/message/fusion/mptspi.ko > >Ah, apt-file search is still a big pain as it doesn't look into udebs even >if I have udeb sources configured… debian-kernel@, sorry for the noise. > >> But this package is also missing on the "release" DVDs for "amd64". >> Nearly every other architecture has this package within an image >> (whether "netinst" oder "DVD"). See >> https://cdimage-search.debian.org/?search_area=release=simple=scsi-modules=Search&.cgifields=search_area&.cgifields=type > >Adding debian-cd@ accordingly. scsi-modules-* has been in the exclude-udebs list since forever... I can remove that if desired? Not sure of exactly why this was added - tracking back through debian-cd history now. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Bug#861898: Please backport SPCR patch for ACPI console on arm64
Source: linux Version: 4.9.25-1 Severity: normal Hi folks, 4.9 already includes ACPI support for arm64, which is great. There's one driver fixup which only went into 4.10, and it would be lovely if you could backport it for 4.9 (and hence Stretch): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10879ae5f12e9cab3c4e8e9504c1aaa8a033bde7 This will make automatic console detection work on any ACPI platform with a pl011 UART, covering lots of arm64 server platforms. Thanks! -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#859641: Please increase USBIP_VHCI_HC_PORTS and USBIP_VHCI_NR_HCS
On Wed, Apr 05, 2017 at 03:51:14PM +0200, Bjørn Mork wrote: >Steve McIntyre <st...@einval.com> writes: > >> In Linaro we're making a lot of use of USB-over-IP devices these days >> for our testing lab. We've hit a (very small!) limit defined in kernel >> config for the number of virtual host controllers and the ports >> allowed per controller. >> >> Currently these are defaulting to >> >> CONFIG_USBIP_VHCI_HC_PORTS=8 >> (can be 1 <= CONFIG_USBIP_VHCI_HC_PORTS <= 31) >> >> and >> CONFIG_USBIP_VHCI_NR_HCS=1 >> (can be 1 <= CONFIG_USBIP_VHCI_NR_HCS <= 128) >> >> The normal limits are very small; could you please raise these to >> (say) 31 and 8 for us? There will obviously be a small increase in >> memory usage in the kernel, but only for users of these particular >> devices. > >FWIW, I believe those constants never should have been accepted. But I >just gave up after getting this answer: >http://www.spinics.net/lists/linux-usb/msg134862.html > >"Because it is easy to implement." was obviously more important than >easy to use... I don't think distro users were considered. ACK. :-/ >If you care about these limits, then I think you should look into what >needs to be done to make them dynamic. I cannot imagine that it is all >that difficult. Which of course is easy to say when you don't actually >plan on doing the work :) Hmmm. I'd love to help , but not *right* now - I've already got a stack of things to do to help get Debian Stretch released! -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Bug#859641: Please increase USBIP_VHCI_HC_PORTS and USBIP_VHCI_NR_HCS
Source: linux Version: 4.9.13-1~bpo8+1 Severity: minor Hi guys, In Linaro we're making a lot of use of USB-over-IP devices these days for our testing lab. We've hit a (very small!) limit defined in kernel config for the number of virtual host controllers and the ports allowed per controller. Currently these are defaulting to CONFIG_USBIP_VHCI_HC_PORTS=8 (can be 1 <= CONFIG_USBIP_VHCI_HC_PORTS <= 31) and CONFIG_USBIP_VHCI_NR_HCS=1 (can be 1 <= CONFIG_USBIP_VHCI_NR_HCS <= 128) The normal limits are very small; could you please raise these to (say) 31 and 8 for us? There will obviously be a small increase in memory usage in the kernel, but only for users of these particular devices. Cheers, Steve -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: jessie won't install/boot on a Dell Poweredge R815
On Fri, Jun 24, 2016 at 06:22:37PM -0400, Jeffrey Mark Siskind wrote: >Please note that bootint with rootdelay=20 does not solve the problem. It only >masks it. > > 1. If I attempt a fresh USB install of jessie, when md0 is correctly built >before the install, the process of doing the fresh install breaks >md0. When it gets to grub install, components of md0 are missing (even >though all six components were present before the install). And >grub-install fails. At this point it is impossible to complete the install >and produce a bootable system. > > 2. If I do a fresh minimal USB install of wheezy, rebuilding md0 in the >process, and then do a dist-upgrade to jessie, I can manually add >rootdelay=20 in grub and boot into jessie with all six components of md0 >present. But if I do so, then after boot, if I do dpkg-reconfigure pc-grub, >doing that gives errors, drops components of md0, precludes me from adding >them back, fails to install grub, and leaves the machine in an unbootable >state. > >I fear that there is a problem writing to disk. Even if I boot with >rootdelay=20, unless the kind of writes that dpkg-reconfigure pc-grub does are >different, doing ordinary writes to disk may also corrupt the disk. > >Please let me know what new information you would like me to gather. Ummm. Checking back up-thread, I can see that you're using md0 across more than 4 disks and you're trying to boot off it with grub-pc. You're hitting BIOS limitations here - the BIOS is only capable of accessing 4 disks. I'm *guessing* that maybe the newer grub in jessie is just being pickier about checking BIOS access to those disks. Try just using 4 of the disks for md0, and I'd expect it to work. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Bug#772578: Missing keyboard modules i2c_designware_*
On Sat, Aug 22, 2015 at 03:23:50PM +0200, Hendrik Weimer wrote: Steve McIntyre st...@einval.com writes: We'll need to make sure that the same set of modules are included in the initramfs generated on the installed system, of course... This doesn't seem to be the case. I just did a fresh install of Debian 8.1 on an Asus X205TA, and the resulting initramfs didn't contain the required modules. The installer was working fine. OK, that's very odd. I've tested this several times on my X205TA since then, and it's always worked flawlessly now. Anything special about the installation options you've chosen? -- Steve McIntyre, Cambridge, UK.st...@einval.com I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds
Bug#785707: Add USB support for APM Mustang
On Sat, May 23, 2015 at 11:45:15AM +0100, Ian Campbell wrote: On Sat, 2015-05-23 at 11:42 +0100, Ian Campbell wrote: Including a v3 which is slightly different to what has been posted here [...] So that's the one I intend to apply Looks like Ben a) already spotted there was a v3 and b) committed it to svn for both Sid and Jessie already, so I shall be doing no such thing! Yay! :-) (Belatedly) tested and working for me - my Mustang happily talks USB now \o/. -- Steve McIntyre, Cambridge, UK.st...@einval.com I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds -- 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/20150601120113.ga18...@einval.com
Bug#785707: Add USB support for APM Mustang
On Thu, May 21, 2015 at 07:49:37PM +0100, Ian Campbell wrote: On Wed, 2015-05-20 at 07:53 +0100, Steve McIntyre wrote: Here's patch v2... Thanks. Has this been posted to anywhere upstream? Usual policy is that this should happen before we take it into our kernel. That will also give us something (i.e. an archive URL) to put in an Origin: header. I'm just pulling out a patch that Mark already sent upstream. Looking for the URL... It's sometimes a PITA that Google likes Debian lists and the BTS so much - most obvious links are just to this bug now! http://www.spinics.net/lists/arm-kernel/msg373699.html We should probably apply this to the sid kernel as well as the jessie one. That would be nice, yes! :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed? -- 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/20150521193351.ga5...@einval.com
Bug#785707: Add USB support for APM Mustang
Here's patch v2...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back
diff -Nru linux-3.16.7-ckt9/debian/changelog linux-3.16.7-ckt9/debian/changelog
--- linux-3.16.7-ckt9/debian/changelog 2015-04-13 01:01:55.0 +
+++ linux-3.16.7-ckt9/debian/changelog 2015-05-15 08:47:00.0 +
@@ -1,3 +1,10 @@
+linux (3.16.7-ckt9-2.1) unstable; urgency=medium
+
+ * arm64: enable XHCI USB on APM X-Gene
+ * usb: host: allow 64-bit DMA mask for XHCI
+
+ -- Steve McIntyre 93...@debian.org Fri, 15 May 2015 09:41:31 +0100
+
linux (3.16.7-ckt9-2) unstable; urgency=medium
* btrfs: simplify insert_orphan_item (Closes: #782362)
diff -Nru linux-3.16.7-ckt9/debian/config/arm64/config
linux-3.16.7-ckt9/debian/config/arm64/config
--- linux-3.16.7-ckt9/debian/config/arm64/config2015-01-02
03:46:07.0 +
+++ linux-3.16.7-ckt9/debian/config/arm64/config2015-05-15
08:54:05.0 +
@@ -120,6 +120,8 @@
CONFIG_USB_EHCI_HCD_PLATFORM=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_HCD_PLATFORM=m
+CONFIG_USB_XHCI_HCD=m
+CONFIG_USB_XHCI_PLATFORM=y
##
## file: drivers/virtio/Kconfig
diff -Nru
linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch
linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch
--- linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch
1970-01-01 00:00:00.0 +
+++ linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch
2015-05-15 10:48:28.0 +
@@ -0,0 +1,61 @@
+From: Mark Langsdorf mlang...@redhat.com
+Date: Wed, 20 May 2015 00:19:13 +0100
+Subject: [usb] make xhci platform driver use 64 bit or 32 bit DMA
+Bug-Debian: https://bugs.debian.org/785707
+Forwarded: no
+
+The xhci platform driver needs to work on systems that either only
+support 64-bit DMA or only support 32-bit DMA. Attempt to set a
+coherent dma mask for 64-bit DMA, and attempt again with 32-bit
+DMA if that fails.
+
+Signed-off-by: Mark Langsdorf mlang...@redhat.com
+Signed-off-by: Steve McIntyre st...@einval.com
+
+Index: linux-3.16.7-ckt9/drivers/usb/host/xhci-plat.c
+===
+--- linux-3.16.7-ckt9.orig/drivers/usb/host/xhci-plat.c
linux-3.16.7-ckt9/drivers/usb/host/xhci-plat.c
+@@ -115,14 +115,18 @@ static int xhci_plat_probe(struct platfo
+ if (!res)
+ return -ENODEV;
+
+- /* Initialize dma_mask and coherent_dma_mask to 32-bits */
+- ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+- if (ret)
+- return ret;
++ /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
++ if (sizeof(dma_addr_t) 8 ||
++ dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
++ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
++ if (ret)
++ return ret;
++ }
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
+ else
+- dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
++ dma_set_mask(pdev-dev, pdev-dev.coherent_dma_mask);
++
+
+ hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
+ if (!hcd)
+Index: linux-3.16.7-ckt9/drivers/usb/host/Kconfig
+===
+--- linux-3.16.7-ckt9.orig/drivers/usb/host/Kconfig
linux-3.16.7-ckt9/drivers/usb/host/Kconfig
+@@ -27,7 +27,13 @@
+ if USB_XHCI_HCD
+
+ config USB_XHCI_PLATFORM
+- tristate
++ tristate Generic XHCI driver for a platform device
++ default n
++ ---help---
++Adds an XHCI host driver for a generic platform device, which
++provides a memory space and an irq.
++
++If unsure, say N.
+
+ config USB_XHCI_MVEBU
+ tristate xHCI support for Marvell Armada 375/38x
diff -Nru linux-3.16.7-ckt9/debian/patches/series
linux-3.16.7-ckt9/debian/patches/series
--- linux-3.16.7-ckt9/debian/patches/series 2015-04-13 00:40:38.0
+
+++ linux-3.16.7-ckt9/debian/patches/series 2015-05-15 08:47:26.0
+
@@ -578,3 +578,4 @@
debian/procfs-avoid-abi-change-in-3.16.7-ckt8.patch
bugfix/all/btrfs-simplify-insert_orphan_item.patch
+features/arm64/xgene-enable-xhci-usb.patch
Bug#785707: Add USB support for APM Mustang
Package: src:linux
Version: 3.16.7-ckt9-2
Severity: normal
Tags: d-i patch
Hi folks,
As described a little at
http://blog.einval.com/2015/05/19#mustang_installer I've been working
on getting Mustang support working. There's a (quite generic!) patch
from Mark Langsdorf for the XHCI platform code that allows for a
64-bit DMA mask:
http://www.spinics.net/lists/arm-kernel/msg373699.html
AFAICS this is needed for the Mustang, as all of its memory is mapped
over 4GiB. The patch hasn't (yet!) been accepted upstream, but I've
swapped mail with Mark and he says he's about to propose it again this
week. With the small attached patch applied to the Jessie kernel
(Mark's code plus a config tweak), I've got things working just fine.
It would be lovely if we could get this into Jessie for the 8.1 point
release. :-)
-- System Information:
Debian Release: 8.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru linux-3.16.7-ckt9/debian/changelog linux-3.16.7-ckt9/debian/changelog
--- linux-3.16.7-ckt9/debian/changelog 2015-04-13 01:01:55.0 +
+++ linux-3.16.7-ckt9/debian/changelog 2015-05-15 08:47:00.0 +
@@ -1,3 +1,10 @@
+linux (3.16.7-ckt9-2.1) unstable; urgency=medium
+
+ * arm64: enable XHCI USB on APM X-Gene
+ * usb: host: allow 64-bit DMA mask for XHCI
+
+ -- Steve McIntyre 93...@debian.org Fri, 15 May 2015 09:41:31 +0100
+
linux (3.16.7-ckt9-2) unstable; urgency=medium
* btrfs: simplify insert_orphan_item (Closes: #782362)
diff -Nru linux-3.16.7-ckt9/debian/config/arm64/config linux-3.16.7-ckt9/debian/config/arm64/config
--- linux-3.16.7-ckt9/debian/config/arm64/config 2015-01-02 03:46:07.0 +
+++ linux-3.16.7-ckt9/debian/config/arm64/config 2015-05-15 08:54:05.0 +
@@ -120,6 +120,8 @@
CONFIG_USB_EHCI_HCD_PLATFORM=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_HCD_PLATFORM=m
+CONFIG_USB_XHCI_HCD=m
+CONFIG_USB_XHCI_PLATFORM=y
##
## file: drivers/virtio/Kconfig
diff -Nru linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch
--- linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch 1970-01-01 00:00:00.0 +
+++ linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch 2015-05-15 10:48:28.0 +
@@ -0,0 +1,40 @@
+Index: linux-3.16.7-ckt9/drivers/usb/host/xhci-plat.c
+===
+--- linux-3.16.7-ckt9.orig/drivers/usb/host/xhci-plat.c
linux-3.16.7-ckt9/drivers/usb/host/xhci-plat.c
+@@ -115,14 +115,18 @@ static int xhci_plat_probe(struct platfo
+ if (!res)
+ return -ENODEV;
+
+- /* Initialize dma_mask and coherent_dma_mask to 32-bits */
+- ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+- if (ret)
+- return ret;
++ /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
++ if (sizeof(dma_addr_t) 8 ||
++ dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
++ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
++ if (ret)
++ return ret;
++ }
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
+ else
+- dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
++ dma_set_mask(pdev-dev, pdev-dev.coherent_dma_mask);
++
+
+ hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
+ if (!hcd)
+Index: linux-3.16.7-ckt9/drivers/usb/host/Kconfig
+===
+--- linux-3.16.7-ckt9.orig/drivers/usb/host/Kconfig
linux-3.16.7-ckt9/drivers/usb/host/Kconfig
+@@ -28,6 +28,7 @@
+
+ config USB_XHCI_PLATFORM
+ tristate
++ default m
+
+ config USB_XHCI_MVEBU
+ tristate xHCI support for Marvell Armada 375/38x
diff -Nru linux-3.16.7-ckt9/debian/patches/series linux-3.16.7-ckt9/debian/patches/series
--- linux-3.16.7-ckt9/debian/patches/series 2015-04-13 00:40:38.0 +
+++ linux-3.16.7-ckt9/debian/patches/series 2015-05-15 08:47:26.0 +
@@ -578,3 +578,4 @@
debian/procfs-avoid-abi-change-in-3.16.7-ckt8.patch
bugfix/all/btrfs-simplify-insert_orphan_item.patch
+features/arm64/xgene-enable-xhci-usb.patch
Bug#785707: Add USB support for APM Mustang
On Tue, May 19, 2015 at 02:20:08PM +0100, Ben Hutchings wrote: On Tue, 2015-05-19 at 12:52 +0100, Steve McIntyre wrote: diff -Nru linux-3.16.7-ckt9/debian/changelog linux-3.16.7-ckt9/debian/changelog --- linux-3.16.7-ckt9/debian/changelog 2015-04-13 01:01:55.0 + +++ linux-3.16.7-ckt9/debian/changelog 2015-05-15 08:47:00.0 + @@ -1,3 +1,10 @@ +linux (3.16.7-ckt9-2.1) unstable; urgency=medium + + * arm64: enable XHCI USB on APM X-Gene + * usb: host: allow 64-bit DMA mask for XHCI + + -- Steve McIntyre 93...@debian.org Fri, 15 May 2015 09:41:31 +0100 + linux (3.16.7-ckt9-2) unstable; urgency=medium * btrfs: simplify insert_orphan_item (Closes: #782362) diff -Nru linux-3.16.7-ckt9/debian/config/arm64/config linux-3.16.7-ckt9/debian/config/arm64/config --- linux-3.16.7-ckt9/debian/config/arm64/config2015-01-02 03:46:07.0 + +++ linux-3.16.7-ckt9/debian/config/arm64/config2015-05-15 08:54:05.0 + @@ -120,6 +120,8 @@ CONFIG_USB_EHCI_HCD_PLATFORM=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_OHCI_HCD_PLATFORM=m +CONFIG_USB_XHCI_HCD=m +CONFIG_USB_XHCI_PLATFORM=y Never specify hidden config symbols under debian/config; it has no effect so it's misleading. ## ## file: drivers/virtio/Kconfig diff -Nru linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch --- linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch 1970-01-01 00:00:00.0 + +++ linux-3.16.7-ckt9/debian/patches/features/arm64/xgene-enable-xhci-usb.patch 2015-05-15 10:48:28.0 + @@ -0,0 +1,40 @@ This patch needs a header. ACK, will add one shortly. +Index: linux-3.16.7-ckt9/drivers/usb/host/xhci-plat.c +=== +--- linux-3.16.7-ckt9.orig/drivers/usb/host/xhci-plat.c linux-3.16.7-ckt9/drivers/usb/host/xhci-plat.c [...] +--- linux-3.16.7-ckt9.orig/drivers/usb/host/Kconfig linux-3.16.7-ckt9/drivers/usb/host/Kconfig +@@ -28,6 +28,7 @@ + + config USB_XHCI_PLATFORM + tristate ++ default m This is wrong; we should not be building USB_XHCI_PLATFORM on every architecture that has USB. Maybe this symbol should be un-hidden instead? I have absolutely no idea how to do that - help please! -- Steve McIntyre, Cambridge, UK.st...@einval.com Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis -- 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/20150519172224.gd4...@einval.com
Bug#785707: Add USB support for APM Mustang
On Tue, May 19, 2015 at 08:03:12PM +0100, Ian Campbell wrote:
On Tue, 2015-05-19 at 20:02 +0100, Ian Campbell wrote:
On Tue, 2015-05-19 at 12:52 +0100, Steve McIntyre wrote:
+CONFIG_USB_XHCI_PLATFORM=y
This guy seems to match on:
static const struct of_device_id usb_xhci_of_match[] = {
{ .compatible = generic-xhci },
{ .compatible = xhci-platform },
{ .compatible = marvell,armada-375-xhci},
{ .compatible = marvell,armada-380-xhci},
{ .compatible = renesas,xhci-r8a7790},
{ .compatible = renesas,xhci-r8a7791},
{ },
But I don't see any of those in the mustang DTBs even in the mainline
kernel.
But I do see them in the latest APM UEFI firmware, so I suppose this
will only work with that and not with e.g. uboot.
That's exactly it, yet - the USB matches are in the latest 1.15.10 APM
drop. I really couldn't care less about trying to support U-Boot with
this stuff - everybody's being told to go UEFI now AFAIK.
Not a blocker per se, I'm not even sure if u-boot can boot from usb
anyhow.
In theory it *can* (I could read files off USB with it), but it's not
going to be useful for this.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
liw everything I know about UK hotels I learned from Fawlty Towers
--
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/20150519220520.gf4...@einval.com
Bug#784761: Missing arm64 DTBs
Package: linux-image-4.0.0-trunk-arm64 Version: 4.0-1~exp1 Severity: serious As mentioned on IRC, this package is missing all the DTBs for arm64 machines. Looks like it's a change to the DTB layout in the upstream tree causing it. -- System Information: Debian Release: 7.8 APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20150508154250.22335.85847.reportbug@tack.local
Bug#784344: Buggy DTB causes imx53 SATA failure
Package: src:linux Version: 3.16.7-ckt9-3~deb8u1 Severity: serious Hi guys, Just debugged on harris.debian.org (imx53, Debian porter box) - there's a missing patch that's needed for the imx53 sata controller to work. At some point, it looks like the code in drivers/ata/ahci_imx.c has changed and arch/arm/boot/dts/imx53.dtsi needed a change to match. It's a trivial change, just renaming the core SATA clock from sata_gate to sata. Upstream patch is in commit 025781539a3ccf867c1e0f2fc63f61cc8c7c5415. (Adding more info for people googling for this!) Without this patch, the SATA driver in drivers/ata/ahci_imx.c just reports [2.377276] ahci-imx 1000.sata: can't get sata clock. [2.425652] ahci-imx: probe of 1000.sata failed with error -2 at startup. Please apply ASAP, would be lovely to get this into the Jessie point release. -- System Information: Debian Release: 7.8 APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20150505162519.2325.77519.reportbug@tack.local
CONFIG_IP_PNP?
Hi guys, I'm wondering if you'd be happy to enable CONFIG_IP_PNP CONFIG_IP_PNP_DHCP in Debian kernels? It would be useful for some simple diskless/nfsroot systems to be able to use standard Debian kernels, e.g. I'm trying to use them for LAVA tests in Linaro. There don't seem to be any major downsides, just a very small amount of extra code size AFAICS. -- Steve McIntyre, Cambridge, UK.st...@einval.com Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis -- 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/20150415161711.gb10...@einval.com
Bug#780858: Massive I/O data corruption on Marvell Armada XP machines
Control: tag -1 +pending On Fri, Mar 20, 2015 at 04:13:20PM +, Steve McIntyre wrote: Package: src:linux Version: 3.16.7-ckt7-1 Severity: grave Tags: upstream Hi folks, We've upgraded a couple of our Marvell Armada XP based (armel/armhf) buildd machines to Jessie, and they've almost immediately fallen over with symptoms of really bad data corruption. On further investigation and discussion with some of the upstream maintainers for this hardware, this is a known issue with I/O coherency and there are patches available for testing: * 8f1e8ee28660018a935c7576b9af8ffe1feab54c is a patch to disable coherency for now, and * http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330104.html is a second patch needed too (do not register custom DMA operations when coherency is disabled) I'm just doing a local build right now with these patches applied so I can test. More news ASAP. Summarising discussion from IRC: Patch #1 above was already applied to the jessie kernel, but patch #2 was not. The bpo kernel we have previously been using had neither, and that worked OK. My testing over the weekend with a locally-built kernel including patch #2 as well was 100% successful, so r22457 looks like it will fix this bug. A prompt upload would be appreciated to get this into Jessie for our buildds! :-) Cheers guys, and thanks very much for the quick replies. -- Steve McIntyre, Cambridge, UK.st...@einval.com You can't barbecue lettuce! -- Ellie Crane -- 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/20150323125313.gc22...@einval.com
Bug#780858: Massive I/O data corruption on Marvell Armada XP machines
Package: src:linux Version: 3.16.7-ckt7-1 Severity: grave Tags: upstream Hi folks, We've upgraded a couple of our Marvell Armada XP based (armel/armhf) buildd machines to Jessie, and they've almost immediately fallen over with symptoms of really bad data corruption. On further investigation and discussion with some of the upstream maintainers for this hardware, this is a known issue with I/O coherency and there are patches available for testing: * 8f1e8ee28660018a935c7576b9af8ffe1feab54c is a patch to disable coherency for now, and * http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330104.html is a second patch needed too (do not register custom DMA operations when coherency is disabled) I'm just doing a local build right now with these patches applied so I can test. More news ASAP. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20150320161320.22658.63802.reportbug@tack.local
Bug#776957: Panic at boot on arm64 systems
Package: src:linux Version: 3.16.7-ckt4-2 Severity: grave Tags: patch upstream The latest upstream stable kernel pull is broken on arm64. The system panics during early boot in arch_timer setup. The cause is simple. Commit 0b46b8a718c6e90910a1b1b0fe797be3c167e186 was pulled into stable, but a later fix d6ad36913083d683aad4e02e53580c995f1a6ede was missed and is necessary. Ian has already taken this patch; please upload a fixed linux ASAP. Cheers, Steve -- 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/20150203143851.24861.48770.reportbug@tack.local
Bug#775191: [PATCH] efi: Expose underlying UEFI firmware platform size to userland
Package: src:linux
Severity: wishlist
Tags: patch
Hi folks,
This patch has been accepted by the efi maintainer for the efi/next
tree. It would be lovely if you'd accept it for the Jessie kernel
too, for the Bay Trail etc. support.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
You can't barbecue lettuce! -- Ellie Crane
From 2859dff97e54db4795b8b7d9606cb8efcec722ff Mon Sep 17 00:00:00 2001
From: Steve McIntyre st...@einval.com
Date: Fri, 9 Jan 2015 15:29:53 +
Subject: [PATCH] efi: Expose underlying UEFI firmware platform size to
userland
In some cases (e.g. Intel Bay Trail machines), the kernel will happily
run in 64-bit even if the underlying UEFI firmware platform is
32-bit. That's great, but it's difficult for userland utilities like
grub-install to do the right thing in such a situation.
The kernel already knows about the size of the firmware via
efi_enabled(EFI_64BIT). Add an extra sysfs interface
/sys/firmware/efi/fw_platform_size to expose that information to
userland for low-level utilities to use.
Signed-off-by: Steve McIntyre st...@einval.com
Cc: Matthew Garrett mj...@srcf.ucam.org
Signed-off-by: Matt Fleming matt.flem...@intel.com
---
drivers/firmware/efi/efi.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index ff0bbe3..9bdbc05 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -112,15 +112,24 @@ EFI_ATTR_SHOW(fw_vendor);
EFI_ATTR_SHOW(runtime);
EFI_ATTR_SHOW(config_table);
+static ssize_t fw_platform_size_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, %d\n, efi_enabled(EFI_64BIT) ? 64 : 32);
+}
+
static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
+static struct kobj_attribute efi_attr_fw_platform_size =
+ __ATTR_RO(fw_platform_size);
static struct attribute *efi_subsys_attrs[] = {
efi_attr_systab.attr,
efi_attr_fw_vendor.attr,
efi_attr_runtime.attr,
efi_attr_config_table.attr,
+ efi_attr_fw_platform_size.attr,
NULL,
};
--
1.7.10.4
Bug#772578: Missing keyboard modules i2c_designware_*
Control: retitle -1 Missing keyboard modules i2c_designware_* in installer Control: tags -1 +patch [ removing the erroneous armhf tag - this is an x86 netbook ] Hi Ben, Here's the patch I've been promising for this. With this patch applied, I've (eventually!) built the kernel then d-i then a netinst locally and I can confirm that the installer now automatically loads the necessary modules: i2c-hid i2c-designware-platform i2c-designware-core (and i2c-core as a dependency of the above modules) With those, the netbook's keyboard and trackpad function correctly for the installer. We'll need to make sure that the same set of modules are included in the initramfs generated on the installed system, of course... -- Steve McIntyre, Cambridge, UK.st...@einval.com I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. -- Charlie Stross Index: debian/installer/modules/i2c-modules === --- debian/installer/modules/i2c-modules (revision 22231) +++ debian/installer/modules/i2c-modules (working copy) @@ -1,2 +1,4 @@ i2c-core i2c-algo-bit +i2c-designware-platform ? +i2c-designware-core ? Index: debian/installer/modules/input-modules === --- debian/installer/modules/input-modules (revision 22231) +++ debian/installer/modules/input-modules (working copy) @@ -28,3 +28,4 @@ hid-topseed ? synaptics_usb ? wistron_btns ? +i2c-hid ? Index: debian/installer/package-list === --- debian/installer/package-list (revision 22231) +++ debian/installer/package-list (working copy) @@ -216,7 +216,7 @@ This package contains Frame buffer drivers for the kernel. Package: input-modules -Depends: kernel-image, usb-modules +Depends: kernel-image, usb-modules, i2c-modules Priority: extra Description: Input devices support This package contains input device drivers for the kernel.
Re: Bug#771465: i386 hd-media image does not boot on Macbooks with 32-bit EFI
On Sun, Nov 30, 2014 at 09:05:47PM +0100, Teemu Ikonen wrote: On Sun, Nov 30, 2014 at 8:48 PM, Teemu Ikonen tpiko...@gmail.com wrote: I made a USB stick with 32-bit EFI grub and kernel and initrd copied from amd64 netboot ISO. Grub naturally works ok, and interestingly, even the kernel boots but it does not find a working init. Ah, of course I mixed the kernel from amd64 and init from i386. With the correct combination (both from amd64 mini.iso) and 32-bit EFI grub the 64-bit installer starts fine. I'm working on two different UEFI setup things right now that will make these machines work better - see http://blog.einval.com/2014/11/20#Jessie-EFI I'm almost done with #746662, just testing now (forcing also installing grub to the removable media path). Next up is the force using a 32-bit UEFI version og grub even for 64-bit systems (#768461) Hopefully a combination of these 2 fixes will make your system work out of the box... -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- 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/20141201002141.gi16...@einval.com
Re: Plan of action for Secure Boot support
On Tue, Aug 19, 2014 at 01:38:44PM -0700, Ben Hutchings wrote: So far as I know, no progress has been made on the above steps or any alternate approach. Ditto, I've not seen (or done) anything about this. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- 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/20140819211641.gi7...@einval.com
Re: Bug#730639: efibootmgr freeze system when creating boot entry
On Wed, Nov 27, 2013 at 07:31:54PM +0400, kasatki...@gmail.com wrote: Subject: efibootmgr freeze system when creating boot entry Package: efibootmgr Version: 0.5.4-7 Severity: important Dear Maintainer, I'm trying to install Debian on Inel UEFI board. The system freezes completely at the end of install phase, when grub (or elilo) tries to create boot menu entry in UEFI BIOS. I've already tried different versions of efibootmgr (from Debian Wheezy, Jessie, also from Ubuntu 13.10 and OpenSuSE 13.1) to no avail. If I run efibootmgr without arguments it works and displays current boot entries. If I understand correctly read works, but not write. The efivars module is loaded: root@goliath:~# lsmod | grep efivars efivars17257 1 efi_pstore There is many entries in /sys/firmware/efi/vars/ The motherboard is Intel Workstation Board S5520SC. Latest firmware update is installed on this board. My current workaround is to install system without bootloader, boot from live USB, comment out efibootmgr calls in /usr/lib/grub/x86_64-efi/grub-install, run grub-install, reboot, manually create EFI boot entry in BIOS setup menu. What can I do to debug this issue? It sounds like you have either a kernel or hardware issue here - efibootmgr just uses the kernel-provided files in /sys as its interface to the hardware. Adding a CC to the kernel list in case anybody there has suggestions... -- Steve McIntyre, Cambridge, UK.st...@einval.com Because heaters aren't purple! -- Catherine Pitt -- 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/20131127153926.ga8...@einval.com
Re: Next (old)stable point releases
On Thu, Sep 05, 2013 at 06:38:41PM +0200, Julien Cristau wrote: On Thu, Sep 5, 2013 at 12:17:54 +0200, Julien Cristau wrote: On Tue, Sep 3, 2013 at 23:09:44 +0100, Adam D. Barratt wrote: [...] - Oct 12-13 - Oct 19-20 Either of those is fine for me. Alright, let's go for Oct 12-13: 7.3 Obviously I meant 7.2... Oct 19-20: 6.0.8 Works for me... -- Steve McIntyre, Cambridge, UK.st...@einval.com This dress doesn't reverse. -- Alden Spiess -- 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/20130905165204.gc12...@einval.com
Re: Next (old)stable point releases
On Mon, Aug 19, 2013 at 03:55:14PM +0200, Julien Cristau wrote: Hi, we should start thinking about dates for the 7.2 and 6.0.8 point releases. Which week-ends in the coming months would work for ftpmaster, press and cd? (We'd need one date for stable and another later for oldstable.) Anything particular that needs to happen on either the kernel or d-i side? I've got a few trips etc. coming up, meaning some of your dates are difficult for me. I've left in the ones that (can) work. Maybe a Doodle would work better overall? - Sep 7-8 - Sep 28-29 - Oct 12-13 - Oct 19-20 -- Steve McIntyre, Cambridge, UK.st...@einval.com Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis -- 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/20130819135923.gc1...@einval.com
Bug#709625: protected_hardlinks is too broad - make it per-filesystem instead?
On Sun, May 26, 2013 at 03:31:03AM +0100, Ben Hutchings wrote: On Fri, 2013-05-24 at 15:30 +0100, Steve McIntyre wrote: Alternatively, I'm pondering: if the main thrust of the hardlink protection is to prevent attacks against system files, then it might make more sense to change protected_hardlinks to be a per-filesystem mount option. By all means protect the root filesystem etc., but for a purely data-carrying filesystem it's a bit obstructive. What do you think? I can see that this could be a useful feature, but I don't think I can spare the time to work on it any time soon. If you have the time to implement this yourself, I would be happy to review the changes but you will need to submit them upstream. OK, understood. I'll see if I can find some tuits... -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there? -- 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/20130530131829.ga15...@einval.com
Bug#709625: protected_hardlinks is too broad - make it per-filesystem instead?
Package: src:linux Version: 3.2.41-2 Severity: normal Hi, I think that the new security feature to restrict hardlinks is a great idea, but it is also causing me problems. In debian-cd, we rely on the ability to make hardlinked copies of files from a debian mirror into temporary disk trees. Since upgrading pettersson (the CD build box), this broke due to the default protected_hardlinks setting. On that system: * we have a push mirror setup using the archvsync user; * we build CDs using as the debian-cd user These two user accounts explicitly don't share credentials: archvsync can be triggered remotely so we don't trust it to be directly involved in the CD build process. The debian-cd user explicitly does not have write access to the mirror area on the machine, so as to ensure we can't/don't make any changes to the mirror when building CDs. For now, on that system we have changed the default settings via /proc but it's not a real solution for us and DSA don't want to do it permanently. I can see a few ways that we could change things: * run things using the same account (not wanted, as described above) * share a group between the users and make everything group-writable (ditto) * come up with a fakelink ld_preload lib like we have fakeroot (eww) Alternatively, I'm pondering: if the main thrust of the hardlink protection is to prevent attacks against system files, then it might make more sense to change protected_hardlinks to be a per-filesystem mount option. By all means protect the root filesystem etc., but for a purely data-carrying filesystem it's a bit obstructive. What do you think? -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- 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/20130524143045.13172.66494.reportbug@tack.local
Bug#595502: [ia64] pata_cmd64x crashes at boot
[ Coming back to this as I'm playing with my ia64 machine a little again... ] On Tue, Dec 11, 2012 at 10:00:53AM +, Steve McIntyre wrote: On Tue, Dec 11, 2012 at 12:32:18AM -0800, Jonathan Nieder wrote: Steve McIntyre wrote: On Sat, Nov 26, 2011 at 12:11:36AM -0600, Jonathan Nieder wrote: But information about what kernels work with IDE disks would certainly be welcome. 2.6.32-46 (the kernel in the latest squeeze point release) shows this problem. On a zx2000 here, it happens almost immediately during filesystem creation when running d-i. Thanks for checking. Sure. In the end, installed Lenny, added a squeeze chroot then rebuilt the squeeze kernel with old-style IDE support instead of pata_cmd64x. That worked fine as a workaround. At Ben's suggestion, I've tried adding kernel command line options to the normal squeeze kernel (linux-image-2.6.32-5-mckinley 2.6.32-46). swiotlb=force makes no noticeable difference, but libata.dma=0 does allow the system to function normally (with the obvious proviso that without DMA disk access is *very* slow). I'm going to see if they help with the Wheezy kernel at all... -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- 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/20130429142917.ga4...@einval.com
Bug#595502: [ia64] pata_cmd64x crashes at boot
On Mon, Apr 29, 2013 at 03:29:17PM +0100, Steve McIntyre wrote: At Ben's suggestion, I've tried adding kernel command line options to the normal squeeze kernel (linux-image-2.6.32-5-mckinley 2.6.32-46). swiotlb=force makes no noticeable difference, but libata.dma=0 does allow the system to function normally (with the obvious proviso that without DMA disk access is *very* slow). I'm going to see if they help with the Wheezy kernel at all... No, not at all. It still fails to boot, triggering a system alarm beep sequence some time after the initramfs is loaded (with no output on serial). I've just decoded the flashing LED codes using the doc at [1]. I've got the System LED flashing red, and Diagnostic LED #3 solid red. That indicates System Board, which is a bit non-specific. Especially considering the system boots fine now using older kernels. [1] http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/lpv00324/lpv00324.pdf -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss -- 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/20130429161313.ge15...@einval.com
Re: 6.0.7 planning
On Sun, Feb 10, 2013 at 04:25:38PM +, Adam Barratt wrote: Hi, We're somewhat overdue with the next Squeeze point release (6.0.7) and it'd be good to get it done before the wheezy release, so that we can pull in some upgrade fixes. As an opening gambit, some proposed dates, all of which appear to currently work for me: February 23rd March 2nd March 9th Of those, Feb 23rd is *vastly* preferable for me. I'm going to be at a conference in Hong Kong for the week of 4th-8th March which means I'll be travelling on the first weekend in March and catching up on sleep on the second. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- 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/20130211012142.gg9...@einval.com
Bug#595502: [ia64] pata_cmd64x crashes at boot
On Tue, Dec 11, 2012 at 12:32:18AM -0800, Jonathan Nieder wrote: Steve McIntyre wrote: On Sat, Nov 26, 2011 at 12:11:36AM -0600, Jonathan Nieder wrote: But information about what kernels work with IDE disks would certainly be welcome. 2.6.32-46 (the kernel in the latest squeeze point release) shows this problem. On a zx2000 here, it happens almost immediately during filesystem creation when running d-i. Thanks for checking. Sure. In the end, installed Lenny, added a squeeze chroot then rebuilt the squeeze kernel with old-style IDE support instead of pata_cmd64x. That worked fine as a workaround. Also found that the kernel in wheezy d-i B4 (linux-image-3.2.0-4-mckinley_3.2.32-1_ia64.deb) causes the machine to lock up while loading the initramfs \o/ :( Maybe a serial console or netconsole could give some hints about what is happening immediately before it locks up? (I doubt it, but might be worth a try.) We're using a serial console already, in fact. No output. But the machine starts warbling and flashing LEDs as though it's caused some kind of machine exception or something. Not sure, I'll see if I can find a manual. If you run into any patches that can help, please don't hesitate to write. ACK. -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- 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/20121211100053.gv4...@einval.com
Bug#595502: [ia64] pata_cmd64x crashes at boot
found 595502 2.6.32-46 thanks On Sat, Nov 26, 2011 at 12:11:36AM -0600, Jonathan Nieder wrote: Jonathan Nieder wrote: I suspect that v3.0-rc1~375^2~7 (pata_cm64x: fix boot crash on parisc, 2011-04-24) fixes it. Looking over the log again, I'm less confident about that. Someone more knowledgeable about the ia64 architecture would presumably have a better idea about what a plausible fix is. (And the high I/O in bug#583917 might have contributed to the symptoms.) But information about what kernels work with IDE disks would certainly be welcome. 2.6.32-46 (the kernel in the latest squeeze point release) shows this problem. On a zx2000 here, it happens almost immediately during filesystem creation when running d-i. :-( Trying to work around that now by doing the filesystem creation on another machine so that we can get a basic installation done, then test different kernels. Also found that the kernel in wheezy d-i B4 (linux-image-3.2.0-4-mckinley_3.2.32-1_ia64.deb) causes the machine to lock up while loading the initramfs \o/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with Valor: Centurion represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. -- 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/20121206164620.ga27...@einval.com
Bug#685143: reassign 685143 to src:linux
As discussed with Ben, this is blatantly a kernel bug. Strace output
attached. The mount() syscall never returns. Debugging further now.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Every time you use Tcl, God kills a kitten. -- Malcolm Ray
2322 execve(/bin/mount, [mount, /dev/sda2, /mnt], [/* 13 vars */]) = 0
2322 brk(0)= 0xba6000
2322 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2322 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f2691368000
2322 access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
2322 open(/etc/ld.so.cache, O_RDONLY) = 3
2322 fstat(3, {st_mode=S_IFREG|0644, st_size=12586, ...}) = 0
2322 mmap(NULL, 12586, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2691364000
2322 close(3) = 0
2322 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2322 open(/lib/x86_64-linux-gnu/libblkid.so.1, O_RDONLY) = 3
2322 read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0Pn\0\0\0\0\0\0..., 832) = 832
2322 fstat(3, {st_mode=S_IFREG|0644, st_size=159856, ...}) = 0
2322 mmap(NULL, 2255016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x7f2690f24000
2322 mprotect(0x7f2690f47000, 2097152, PROT_NONE) = 0
2322 mmap(0x7f2691147000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23000) = 0x7f2691147000
2322 close(3) = 0
2322 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2322 open(/lib/x86_64-linux-gnu/libselinux.so.1, O_RDONLY) = 3
2322 read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\260f\0\0\0\0\0\0..., 832) = 832
2322 fstat(3, {st_mode=S_IFREG|0644, st_size=126232, ...}) = 0
2322 mmap(NULL, 2226160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x7f2690d04000
2322 mprotect(0x7f2690d22000, 2093056, PROT_NONE) = 0
2322 mmap(0x7f2690f21000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d000) = 0x7f2690f21000
2322 mmap(0x7f2690f23000, 2032, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2690f23000
2322 close(3) = 0
2322 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2322 open(/lib/x86_64-linux-gnu/libsepol.so.1, O_RDONLY) = 3
2322 read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320F\0\0\0\0\0\0..., 832) = 832
2322 fstat(3, {st_mode=S_IFREG|0644, st_size=261184, ...}) = 0
2322 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f2691363000
2322 mmap(NULL, 2358112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x7f2690ac4000
2322 mprotect(0x7f2690b03000, 2093056, PROT_NONE) = 0
2322 mmap(0x7f2690d02000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3e000) = 0x7f2690d02000
2322 close(3) = 0
2322 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2322 open(/lib/x86_64-linux-gnu/libmount.so.1, O_RDONLY) = 3
2322 read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\300x\0\0\0\0\0\0..., 832) = 832
2322 fstat(3, {st_mode=S_IFREG|0644, st_size=163840, ...}) = 0
2322 mmap(NULL, 2258960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x7f269089c000
2322 mprotect(0x7f26908c2000, 2097152, PROT_NONE) = 0
2322 mmap(0x7f2690ac2000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f2690ac2000
2322 close(3) = 0
2322 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2322 open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY) = 3
2322 read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\300\357\1\0\0\0\0\0..., 832) =
832
2322 fstat(3, {st_mode=S_IFREG|0755, st_size=1583120, ...}) = 0
2322 mmap(NULL, 3696728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x7f2690515000
2322 mprotect(0x7f2690692000, 2097152, PROT_NONE) = 0
2322 mmap(0x7f2690892000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17d000) = 0x7f2690892000
2322 mmap(0x7f2690897000, 18520, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2690897000
2322 close(3) = 0
2322 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2322 open(/lib/x86_64-linux-gnu/libuuid.so.1, O_RDONLY) = 3
2322 read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\0\31\0\0\0\0\0\0..., 832) = 832
2322 fstat(3, {st_mode=S_IFREG|0644, st_size=18896, ...}) = 0
2322 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f2691362000
2322 mmap(NULL, 2113968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x7f269031
2322 mprotect(0x7f2690314000, 2093056, PROT_NONE) = 0
2322 mmap(0x7f2690513000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f2690513000
2322 close(3
Reassigning [was Cannot install on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card]
reassign 699416 firmware-iwlwifi thanks Reassigning to firmware-iwlwifi, not a CD-specific issue... -- Steve McIntyre, Cambridge, UK.st...@einval.com liw everything I know about UK hotels I learned from Fawlty Towers -- 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/20121002155316.ga25...@einval.com
Re: Squeeze point release (6.0.6)
On Fri, Sep 07, 2012 at 09:43:03PM +0200, Philipp Kern wrote: Hi, I'd like to arrange a point release to be done as soon as feasible. So I'd like to propose a bunch of weekends here: * Sep 22/23: I'm personally busy on the 23th Available that weekend fine. * Sep 29/30: ok from RT side Available that weekend fine. * Oct 6/7: Adam's busy for the weekend, hence we'd like to avoid that if possible Ditto, I'm guessing the same event :-) * Oct 13/14: BSP attended by adsb/Sledge, not ideal to schedule it there Worked OK at the last BSP we did, tbh... So dear FTP masters, CD team, Press team: Would one out of Sep 22/29/30 work out for all of you? Dear Kernel team: Which changes are still pending for 6.0.6? When could we get them into the archive? For 22nd we'd close p-u-NEW on the 15th, which would leave us with a week. Kind regards Philipp Kern -- Steve McIntyre, Cambridge, UK.st...@einval.com C++ ate my sanity -- Jon Rabone -- 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/20120914122252.gc24...@einval.com
Bug#684265: testing report [Re: Bug#686471: cdimage.debian.org: Please made DVD-1 image small enough to fit on a 4GB USB stick]
On Thu, Sep 06, 2012 at 11:36:31PM -0700, Rick Thomas wrote: Well, it wasn't Tuesday. More like Thursday, but I did manage to get to it today. Here's my report... I downloaded both the amd64 and powerpc weekly DVD-1 iso's from 9/3/2012 and copied each to a 4 GB USB flash thumb-drive, using dd. Each booted as expected and ran the install process thru partitioning, telling it *not* to use a mirror (wanting to make sure the smaller DVD-1 installer wasn't missing anything important), then, finally, running task selection and finishing the installation. I installed a standard desktop environment: gnome on the powerpc, and xfce on the amd64. When it came time to write the boot-loader, they both showed symptoms of bug #684265 -- not able to find existing OS's and make entries for them in the bootloader config file. Fortunately, the amd64 grub boot loader creation script did some self-checking, and noticed that there was only one OS in the setup it was about to write. It asked me if I wanted to write a MBR that I'd only have to re-do later to pick up the other OS's (if any). I decided to see if there were other options and answered no. It then asked if I wanted to write the boot block to the partition I was installing to. I said yes but that failed for some reason (I don't remember the error message, and I don't think it was helpful even if I could remember.) So then I tried using lilo to a second USB stick. That worked and booted fine. If I booted without the USB stick, it booted to the previous default OS. Cool! that there's a workaround, but Uncool! that it's so roundabout! I'll be happy to supply the syslog file if you want to take a look. The powerpc yaboot boot loader creation script isn't so intelligent. It didn't check, and therefor didn't recognize there was a problem, so it went blithely ahead and created a one-entry yaboot configuration, which I had to repair manually after rebooting. Once again, I have the syslog file from this installation and I'll be happy to supply it if you want to take a look. If you can point me at which package I should post a wishlist bug to, I'd love to have the yaboot bootloader creation script be as smart as the one for grub about Hey! There's only one OS here. With the above-described workarounds, all went well with the post- installation reboots. The respective desktop environments seem complete and fully-functional. Cool, thanks for checking that. I'm closing #686471 now. :-) PS: Is anybody working on bug #684265? It would be a shame if it got into beta2... Yes, it would... -- Steve McIntyre, Cambridge, UK.st...@einval.com Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis -- 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/20120913151057.gc29...@einval.com
Re: Squeeze point release (6.0.5)
On Thu, Apr 26, 2012 at 12:22:18PM +0100, Mark Hymers wrote: On Wed, 25, Apr, 2012 at 09:32:51PM +0100, Steve McIntyre spoke thus.. That will help, but then the issue is more a problem with downloading the images. I've got a full mirror at home, which helps immensely with jigdo downloads. I can try and arrange to have a full local mirror at the BSP which I can sync at work on the Friday beforehand if that'll help. Cool, that would be good. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control. -- 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/20120426113523.gn21...@einval.com
Re: Squeeze point release (6.0.5)
On Wed, Apr 25, 2012 at 09:25:17PM +0100, Jonathan Wiltshire wrote: On Tue, Apr 24, 2012 at 09:22:12PM +0100, Steve McIntyre wrote: On Tue, Apr 24, 2012 at 09:06:01PM +0100, Adam Barratt wrote: May 12/13: York BSP. Probably not the best time for CDs, given that Steve would be at the wrong end of the country. (As will I, but that's less of an issue) Not a *major* problem for a point release, but it will slow down the CD release until I can test. On the other hand, you should have at least a few willing vict^w^w helpers in the same place to test CDs with you, which might even speed things up. That will help, but then the issue is more a problem with downloading the images. I've got a full mirror at home, which helps immensely with jigdo downloads. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- 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/20120425203250.gk21...@einval.com
Re: Squeeze point release (6.0.5)
On Tue, Apr 24, 2012 at 09:06:01PM +0100, Adam Barratt wrote: Hi, 6.0.5 is somewhat overdue now and I've been procrastinating over organising it for a while. So before I find something else to distract myself with, some suggested dates: May 5/6: Probably doable; would mean we need to close p-u-NEW over the coming weekend. Possible, but not ideal for me. May 12/13: York BSP. Probably not the best time for CDs, given that Steve would be at the wrong end of the country. (As will I, but that's less of an issue) Not a *major* problem for a point release, but it will slow down the CD release until I can test. May 19/20: Works for me. May 26/27: No chance, I'll be in Hong Kong on a work trip! -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- 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/20120424202212.gd21...@einval.com
