Re: Plan of action for Secure Boot support
* Colin Watson: On Wed, Jan 08, 2014 at 08:31:11AM +0100, Florian Weimer wrote: Furthermore, we need to store the keys for all EV certificates (both the certificate used for submission, and the certificate embedded in the shim) in devices that meet at least FIPS 140 Level 2. Such devices that are affordable, support secure, remote operation, and are compatible with free software environments are difficult to find. (But perhaps we can find a DD who agrees to keep the keys in his or her home and manually signs our kernels, using Windows if necessary.) We (Canonical) have been trying to get this requirement made a bit more sane; we keep our SB root certificate split up among a number of shareholders using gfshare, which we believe should be functionally adequate for this. Steve Langasek may know where this sits. Have you had any success in this endeavor? -- 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/87siny87ss@mid.deneb.enyo.de
Bug#748805: System fails to boot after upgrading to linux-image-3.14-0.bpo.1-amd64 from wheezy-backports
On Sun, May 25, 2014 at 01:33:38AM +0100, Ben Hutchings wrote: There should be a message in the kernel log telling you exactly what was not found in btrfs. You could run: 'dmesg | grep btrfs'. dmesg's output doesn't contain 'btrfs', 'format', 'mount', or even 'module'. Nils -- 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/20140525114020.ga6...@voidptr.de
Re: [PATCH 2/7] ppc64el: kernel: config: little-endian powerpc64 options
On Sat, May 24, 2014 at 06:18:57PM -0300, Mauricio Faria de Oliveira wrote: --- /dev/null +++ b/debian/config/kernelarch-powerpc/config-arch-64-le @@ -0,0 +1,74 @@ +## +## file: arch/powerpc/Kconfig +## +CONFIG_CRASH_DUMP=y +CONFIG_PPC_64K_PAGES=y +CONFIG_PPC_TRANSACTIONAL_MEM=y Nothing of this is le specific. +## +## file: arch/powerpc/platforms/Kconfig.cputype +## +CONFIG_CPU_LITTLE_ENDIAN=y This is. +CONFIG_PPC_BOOK3S_64=y +CONFIG_POWER7_CPU=y +CONFIG_VSX=y +CONFIG_NR_CPUS=2048 This not. +## +## file: arch/powerpc/platforms/powermac/Kconfig +## +#. This must be explicitly disabled (it's enabled by default). +# CONFIG_PPC_PMAC is not set Please explain? If it does not work, it needs a depends on !CPU_LITTLE_ENDIAN. +## +## file: arch/powerpc/platforms/powernv/Kconfig +## +CONFIG_PPC_POWERNV=y Does not depend on CPU_LITTLE_ENDIAN. +## +## file: arch/powerpc/platforms/pseries/Kconfig +## +CONFIG_LPARCFG=y +CONFIG_PPC_SPLPAR=y +CONFIG_PPC_SMLPAR=y +CONFIG_DTL=y Explain? +## +## file: drivers/cpufreq/Kconfig +## +## choice: Default CPUFreq governor +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set +## end choice No. You have to specify it for all similar. +## +## file: drivers/net/ethernet/ibm/Kconfig +## +#. qemu-kvm with kernel only (no initrd). +CONFIG_IBMVETH=y qemu supports initrd. +## +## file: kernel/Kconfig.hz +## +## choice: Timer frequency +CONFIG_HZ_100=y +# CONFIG_HZ_250 is not set +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +## end choice No. Bastian -- History tends to exaggerate. -- Col. Green, The Savage Curtain, stardate 5906.4 -- 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/20140525113122.ga8...@mail.waldi.eu.org
Re: [PATCH 3/7] ppc64el: kernel: config: split common/big-endian powerpc64 options
On Sat, May 24, 2014 at 06:18:58PM -0300, Mauricio Faria de Oliveira wrote: index 269ddb0..77baad1 100644 --- a/debian/config/kernelarch-powerpc/config-arch-64 +++ b/debian/config/kernelarch-powerpc/config-arch-64 @@ -1,12 +1,8 @@ ## ## file: arch/powerpc/Kconfig ## -# CONFIG_CRASH_DUMP is not set You enabled this in the last patch, so it is clearly not big endian specific. Otherwise remove it from the other file. CONFIG_IRQ_ALL_CPUS=y CONFIG_NUMA=y -## choice: Page size -# CONFIG_PPC_64K_PAGES is not set -## end choice Hu? -CONFIG_NR_CPUS=32 The same as above. Bastian -- War isn't a good life, but it's life. -- Kirk, A Private Little War, stardate 4211.8 -- 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/20140525113407.gb8...@mail.waldi.eu.org
Re: [PATCH 4/7] ppc64el: kernel: patch: temporarily disable zImage
On Sat, May 24, 2014 at 06:18:59PM -0300, Mauricio Faria de Oliveira wrote: Debian ppc64el will wait for the 'powerpc/boot: 64bit little endian wrapper' (zImage) patches upstream rather than shipping 32-bit tools for zImage. And why do you add workarounds instead of the real patch? Bastian -- We Klingons believe as you do -- the sick should die. Only the strong should live. -- Kras, Friday's Child, stardate 3497.2 -- 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/20140525113450.gc8...@mail.waldi.eu.org
Re: [PATCH 5/7] ppc64el: kernel: patch: one patch for the PowerNV platform
On Sat, May 24, 2014 at 06:19:00PM -0300, Mauricio Faria de Oliveira wrote: This patch didn't make mainline yet (3.15-rc6). And why? Which tree currently holds it? Bastian -- No one may kill a man. Not for any purpose. It cannot be condoned. -- Kirk, Spock's Brain, stardate 5431.6 -- 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/20140525113640.gd8...@mail.waldi.eu.org
Bug#748805: Possible cause found
On Sun, May 25, 2014 at 04:39:49AM +0200, Tristan Seligmann wrote: I added libcrc32c to /etc/initramfs-tools/modules and reran update-initramfs; this seems to have solved the problem. Worked for me, too. This also explains why the other system (the one previously running on an XFS rootfs) worked without the workaround: xfs.ko requires libcrc32c, so the module was included in the initramfs by default, even after the xfs module was no longer needed. -- 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/20140525120602.ga8...@voidptr.de
Re: [PATCH 5/7] ppc64el: kernel: patch: one patch for the PowerNV platform
On Sat, 2014-05-24 at 18:19 -0300, Mauricio Faria de Oliveira wrote: This patch didn't make mainline yet (3.15-rc6). This is required for booting in the PowerNV (non-virtualized) platform in little-endian mode. Sources: - https://github.com/torvalds/linux/commit/5072b7ba14de2b02b1d68f85dc5e81980e1818e7 - http://patchwork.ozlabs.org/patch/350461/ [...] Please put one of these URLs in the 'Origin' header of the added patch file. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part
Bug#722402: marked as done (firmware-linux-nonfree: Requesting AMD Radeon Kaveri firmware)
Your message dated Sun, 25 May 2014 08:41:45 -0400 with message-id 5381e509.3010...@gmail.com and subject line Fixed has caused the Debian Bug report #722402, regarding firmware-linux-nonfree: Requesting AMD Radeon Kaveri firmware to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 722402: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722402 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: firmware-linux-nonfree Version: 0.40 Severity: normal AMD Radeon Kaveri firmware is now available: http://people.freedesktop.org/~agd5f/radeon_ucode/ Please add it to the firmware-linux-nonfree package as it will suppress the missing firmware warning messages and ensure that users have the needed firmware when Kaveri chips are available. See also: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1218691 Thanks -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-10.towo-siduction-amd64 (SMP w/3 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash firmware-linux-nonfree depends on no packages. firmware-linux-nonfree recommends no packages. Versions of packages firmware-linux-nonfree suggests: ii initramfs-tools 0.113 ii linux-image-3.10-10.towo-siduction-amd64 [linux-image] 3.10-10 ii linux-image-3.11-0.towo-siduction-amd64 [linux-image] 3.11-1 -- no debconf information ---End Message--- ---BeginMessage--- Package: firmware-linux-nonfree Version: 0.41 Severity: normal firmware-nonfree (0.41) unstable; urgency=medium * linux-nonfree: Add Radeon HD 7790/8770/8950 series SMC microcode, Radeon R9 290 series and Radeon R5/R7 IGP 200 series microcode ---End Message---
Bug#748701: linux-image-3.14-1-686-pae: Laptop screen dim. Brightness controls do not function
The same (or similar) issue here! After upgrading from linux-image-3.13.1 to 3.14.1, the screen on my laptop (a Dell Latitude D630) turn screen to black all time I remove the AC cord from energy plug and all the time I plug de AC cord to energy plug. If I leave the laptop until it change the screen to black, to save energy, the fn+birghtness not function any more: screen turn black and I need to boot the system. Booting to the kernel image 3.13-1, using grub, resolves that issue. However, all time I not remember to change this at the grub and the system go a head using 3.14.1. -- Laia, ML -- 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/20140525150236.GA10524@localhost
Bug#748805: Possible cause found
On 5/24/14, Tristan Seligmann mithra...@mithrandi.net wrote: [...] I added libcrc32c to /etc/initramfs-tools/modules and reran update-initramfs; this seems to have solved the problem. I tried this, and it does not solve the problem for me. My /root filesystem is an ext4 partition on a physical hard disk, /dev/sda3 not a btrfs -- 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/cabeukpf6b028_uuf-vqgr1fyvtps5zhwv5foyn7kstfyqqe...@mail.gmail.com
Bug#748805: Maybe this should be a separate bug?
On 5/25/14, Lou Poppler loupopp...@cableone.net wrote: On 5/24/14, Tristan Seligmann mithra...@mithrandi.net wrote: [...] I added libcrc32c to /etc/initramfs-tools/modules and reran update-initramfs; this seems to have solved the problem. I tried this, and it does not solve the problem for me. My /root filesystem is an ext4 partition on a physical hard disk, /dev/sda3 not a btrfs Since my 3.14-0.bpo.1.-amd64 installation hangs apparently sooner than the others being discussed in this thread (i.e. the last message I see is Booting the kernel.) maybe it is not the same bug ? Is there anything else I should experiment with, or any other source of information I could provide ? Thanks, Lou -- Power corrupts. Absolute power is kind of neat -- John Lehman, Secretary of the Navy 1981-1987 -- 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/cabeukpfchd-lxevwudnobb2kzbz4ua2e9pd4w2suj-qwgc1...@mail.gmail.com
Bug#748805: Possible cause found
On Sun, May 25, 2014 at 08:45:31AM -0700, Lou Poppler wrote: On 5/24/14, Tristan Seligmann mithra...@mithrandi.net wrote: I tried this, and it does not solve the problem for me. My /root filesystem is an ext4 partition on a physical hard disk, /dev/sda3 not a btrfs You seem to be experiencing a different bug (your system hangs before it even gets far enough to load any modules), so you might want to file a separate bug report. -- 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/20140525160134.ga22...@voidptr.de
Processing of linux_3.15~rc6-1~exp1_multi.changes
linux_3.15~rc6-1~exp1_multi.changes uploaded successfully to localhost along with the files: linux-support-3.15-rc6_3.15~rc6-1~exp1_all.deb linux-doc-3.15_3.15~rc6-1~exp1_all.deb linux-manual-3.15_3.15~rc6-1~exp1_all.deb linux-source-3.15_3.15~rc6-1~exp1_all.deb linux_3.15~rc6-1~exp1.dsc linux_3.15~rc6.orig.tar.xz linux_3.15~rc6-1~exp1.debian.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1wob55-0004ln...@franck.debian.org
Bug#749273: Enable CONFIG_INTEL_SMARTCONNECT
Package: src:linux Version: 3.14.4-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! SmartConnect is a new feature from Intel allowing a computer to wake up at regular interval to do some tasks like retrieving mails or stuff like that. On my PC, when enabled, it makes suspend or resume randomly fail. There is a module to support this new feature. Currently, it just disables it to avoid any problem since Linux doesn't know how to handle that (I suppose this is not a regular wake up). My guess is that compiling this module would avoid problems with configurations like mine without disabling SmartConnect in the BIOS (which may be difficult to know about). - -- Package-specific info: ** Version: Linux version 3.14-1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-21) ) #1 SMP Debian 3.14.4-1 (2014-05-13) ** Command line: BOOT_IMAGE=/vmlinuz-3.14-1-amd64 root=/dev/mapper/neo-root ro i8042.reset=1 acpi_osi=Linux init=/bin/systemd ** Tainted: WCO (5632) * Taint on warning. * Module from drivers/staging has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [353899.448375] pci :03:00.0: bridge window [mem 0xdf60-0xdf7f] [353899.448380] pci :03:00.0: bridge window [mem 0xdf80-0xdf9f 64bit pref] [353899.448392] pci :03:00.0: no hotplug settings from platform [353900.501910] r8169 :02:00.0 eth0: link up [353900.788033] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [353904.523048] Suspending console(s) (use no_console_suspend to debug) [353904.523351] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [353904.523362] sd 0:0:0:0: [sda] Synchronizing SCSI cache [353904.523512] sd 0:0:0:0: [sda] Stopping disk [353904.546738] sd 1:0:0:0: [sdb] Stopping disk [353904.624080] hub 1-0:1.0: port 4 not suspended yet [353905.624118] PM: suspend of devices complete after 1100.960 msecs [353905.624201] PM: late suspend of devices complete after 0.081 msecs [353905.624401] r8169 :02:00.0: System wakeup enabled by ACPI [353905.640098] ehci-pci :00:1d.0: System wakeup enabled by ACPI [353905.644117] ehci-pci :00:1a.0: System wakeup enabled by ACPI [353905.652045] xhci_hcd :00:14.0: System wakeup enabled by ACPI [353905.656399] PM: noirq suspend of devices complete after 32.196 msecs [353905.656591] ACPI: Preparing to enter system sleep state S3 [353905.656821] PM: Saving platform NVS memory [353905.657347] Disabling non-boot CPUs ... [353905.658553] kvm: disabling virtualization on CPU1 [353905.760020] smpboot: CPU 1 is now offline [353905.761457] kvm: disabling virtualization on CPU2 [353905.864010] smpboot: CPU 2 is now offline [353905.865370] kvm: disabling virtualization on CPU3 [353905.968010] smpboot: CPU 3 is now offline [353905.968111] ACPI: Low-level resume complete [353905.968111] PM: Restoring platform NVS memory [353905.968111] Enabling non-boot CPUs ... [353905.968111] x86: Booting SMP configuration: [353905.968111] smpboot: Booting Node 0 Processor 1 APIC 0x2 [353905.658554] kvm: enabling virtualization on CPU1 [353905.980382] Intel pstate controlling: cpu 1 [353905.980416] CPU1 is up [353905.980469] smpboot: Booting Node 0 Processor 2 APIC 0x4 [353905.761459] kvm: enabling virtualization on CPU2 [353905.992491] Intel pstate controlling: cpu 2 [353905.992521] CPU2 is up [353905.992575] smpboot: Booting Node 0 Processor 3 APIC 0x6 [353905.865371] kvm: enabling virtualization on CPU3 [353906.004606] Intel pstate controlling: cpu 3 [353906.004636] CPU3 is up [353906.007136] ACPI: Waking up from system sleep state S3 [353906.016045] xhci_hcd :00:14.0: System wakeup disabled by ACPI [353906.024042] ehci-pci :00:1a.0: System wakeup disabled by ACPI [353906.032040] ehci-pci :00:1d.0: System wakeup disabled by ACPI [353906.052234] PM: noirq resume of devices complete after 44.635 msecs [353906.052338] PM: early resume of devices complete after 0.086 msecs [353906.052426] snd_hda_intel :00:03.0: irq 43 for MSI/MSI-X [353906.052497] mei_me :00:16.0: irq 45 for MSI/MSI-X [353906.052582] r8169 :02:00.0: System wakeup disabled by ACPI [353906.052725] snd_hda_intel :00:1b.0: irq 46 for MSI/MSI-X [353906.094429] r8169 :02:00.0 eth0: link down [353906.396058] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [353906.396856] ata2.00: failed to get NCQ Send/Recv Log Emask 0x1 [353906.496373] ata2.00: failed to get NCQ Send/Recv Log Emask 0x1 [353906.496432] ata2.00: configured for UDMA/133 [353906.496609] sd 1:0:0:0: [sdb] Starting disk [353907.804061] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [353907.850450] r8169 :02:00.0 eth0: link up [353911.428041] ata1: link is slow to respond, please be patient (ready=0) [353911.932060] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [353911.965782] ata1.00: configured for UDMA/133 [353911.965846] sd 0:0:0:0: [sda] Starting disk [353911.977187] PM: resume of devices complete after 5924.848 msecs
Re: [PATCH 2/7] ppc64el: kernel: config: little-endian powerpc64 options
Hi Bastian, Thanks for your insightful comments. Let me try to expose the rationale I had in mind for putting in the config file the options you commented. The general rationale is not to be intrusive in the ppc64 port's config: - If an option /differs/ between ppc64 and ppc64el, I put either in the specific -be and -le file. I didn't change it in the ppc64 config if I didn't know why it was set there in that way (which happens to be the case for all of them :-). So, I just humbly decided not to touch what I don't understand. I'd be happy to submit changes if they're acknowledged by experienced people. - If an option /does not exist/ in the ppc64 config (mainly options for the platforms we have for little-endian powerpc64 nowadays), I chose not to put it there if: - if it could penalize performance or even functionality (say, cpu-specific tuning; kernel overhead) - if it's specific to the currently available powerpc64le platforms (which are PPC_BOOK3S_64). Again, not to be intrusive in the ppc64 config, adding stuff; but I'd be OK to add those if acknowledged by maintainers). Now let me go through each comment below, with that rationale in mind. On 05/25/2014 08:31 AM, Bastian Blank wrote: On Sat, May 24, 2014 at 06:18:57PM -0300, Mauricio Faria de Oliveira wrote: --- /dev/null +++ b/debian/config/kernelarch-powerpc/config-arch-64-le @@ -0,0 +1,74 @@ +## +## file: arch/powerpc/Kconfig +## +CONFIG_CRASH_DUMP=y +CONFIG_PPC_64K_PAGES=y - CRASH_DUMP is not enabled on ppc64. I don't know why, so didn't change it. - PPC_64K_PAGES neither. I imagine it might not be the best setting for most powerpc64 systems out there (powermacs, I believe), but it is a /must/ for POWER servers and systems expected to run ppc64el (currently POWER8-based). Smaller page sizes (i.e., 4k) do incur a significant performance hit (sorry, I don't know a number); I believe it's the main reason the page size is 64k on every distro running on POWER servers. And I think it's not an optimal setting for other powerpc-based systems (powermacs, others). So, since that one seems required to be different among ppc64/ppc64el I did so. +CONFIG_PPC_TRANSACTIONAL_MEM=y This one because it depends on PPC_BOOK3S_64, which can't be enabled on the ppc64 port (at least on a 'general' flavor, which is the case currently), since it 'selects' many processors options not available on some powerpc processors (I think Performance Monitoring Unit is the main one). Perhaps if a new ppc64 flavor is created for holding the PPC_BOOK3S_64 options, we can put it (and other options depending on it) there, and then include it in the ppc64el defines. I'd be happy to work on that. Nothing of this is le specific. Agreed, but set in that way for the reasons explained above. +## +## file: arch/powerpc/platforms/Kconfig.cputype +## +CONFIG_CPU_LITTLE_ENDIAN=y This is. +CONFIG_PPC_BOOK3S_64=y As discussed above. +CONFIG_POWER7_CPU=y Similarly, depends on PPC_BOOK3S_64, and also incurs performance hit (or even break on other processors) due to tuning to a particular CPU. Just for the record (I'm sure you understand this), an excerpt from Kconfig.cputype: This will create a kernel which is optimised for a particular CPU. The resulting kernel may not run on other CPUs, so use this with care. +CONFIG_VSX=y This one should be OK for other powerpc processors, but I understand it adds kernel code/overhead, so I chose not to put it in ppc64. From Kconfig.cputype: This option is only useful if you have a processor that supports VSX (P7 and above), but does not have any affect on a non-VSX CPUs (it does, however add code to the kernel). +CONFIG_NR_CPUS=2048 This should be OK too, but not sure it incurs noticeable overhead. I see this bitmap on kernel/cpu.c, whose size depends on NR_CPUS. (didn't find much else depending on the NR_CPUS definition). const unsigned long cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)] That bitmap might go around over the system.. I wouldn't know exactly its impact; so I chose not to change the value in ppc64. This not. Reasons explained above. +## +## file: arch/powerpc/platforms/powermac/Kconfig +## +#. This must be explicitly disabled (it's enabled by default). +# CONFIG_PPC_PMAC is not set Please explain? If it does not work, it needs a depends on !CPU_LITTLE_ENDIAN. Yes, I agree. I'm not sure why it is not set that way (maybe oversight) but that also happens to be the case with other Cell, PS3 and other platforms known not to support taking interrupts in little endian mode (ILE) as they are currently, therefore unable to run ppc64el as-is. The main reason I explicitly disable PPC_PMAC is that it helpfully disables a ton of stuff that (thankfully) 'depends on' it (say drivers, windfarm, cpufreq and others), saving many lines from being moved from ppc64 config to ppc64-be -- keeping things simple. Unfortunately
Re: [PATCH 3/7] ppc64el: kernel: config: split common/big-endian powerpc64 options
On 05/25/2014 08:34 AM, Bastian Blank wrote: On Sat, May 24, 2014 at 06:18:58PM -0300, Mauricio Faria de Oliveira wrote: index 269ddb0..77baad1 100644 --- a/debian/config/kernelarch-powerpc/config-arch-64 +++ b/debian/config/kernelarch-powerpc/config-arch-64 @@ -1,12 +1,8 @@ ## ## file: arch/powerpc/Kconfig ## -# CONFIG_CRASH_DUMP is not set You enabled this in the last patch, so it is clearly not big endian specific. Otherwise remove it from the other file. For reference, please see the rationale explained in the reply I just sent for patch 2/7. CONFIG_IRQ_ALL_CPUS=y CONFIG_NUMA=y -## choice: Page size -# CONFIG_PPC_64K_PAGES is not set -## end choice Hu? -CONFIG_NR_CPUS=32 The same as above. Likewise. Bastian -- Mauricio Faria de Oliveira IBM Linux Technology Center -- 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/5382667e.8070...@linux.vnet.ibm.com
Re: [PATCH 4/7] ppc64el: kernel: patch: temporarily disable zImage
On 05/25/2014 08:34 AM, Bastian Blank wrote: On Sat, May 24, 2014 at 06:18:59PM -0300, Mauricio Faria de Oliveira wrote: Debian ppc64el will wait for the 'powerpc/boot: 64bit little endian wrapper' (zImage) patches upstream rather than shipping 32-bit tools for zImage. And why do you add workarounds instead of the real patch? Mainly because it's a large patch-set (15 patches) [1, 2]. Since we don't really need a zImage now (we're using vmlinux), and both patches (either workaround or that patchset) would achieve the effect of removing the build error, I opted for the small workaround. I'm ok to put the patch-set in, instead. Thanks, [1] https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg77325.html [2] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?qt=grepq=powerpc%2Fboot (15 commits with message prefix 'powerpc/boot:' dated of 2014-04-28) -- Mauricio Faria de Oliveira IBM Linux Technology Center -- 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/53826737.70...@linux.vnet.ibm.com
Re: [PATCH 5/7] ppc64el: kernel: patch: one patch for the PowerNV platform
On 05/25/2014 08:36 AM, Bastian Blank wrote: On Sat, May 24, 2014 at 06:19:00PM -0300, Mauricio Faria de Oliveira wrote: This patch didn't make mainline yet (3.15-rc6). And why? Which tree currently holds it? That I'm not sure, but it's carried on other distros, and being (re)posted by the powerpc kernel guys. Maybe because it had a different version made available recently, but it was preferred to keep with an older version [1], which was in Linus's github tree once [2], and is on Ubuntu Trusty's kernel [3]. It's not yet on Ben H (ok, Herrenschmidt this time; it seems 'benh' nicknamed people tend to like kernels and powerpc stuff :-) 's linux-next tree [4]; but I think it's because of the 'recently' discussed reason/re-posted on linuxppc-dev [5]. So, it's expected to be submitted to -next in some time, since it's acknowledged to be required. I just happen to don't know why. I can ask Ben for further clarification if needed. Thanks, [1] http://patchwork.ozlabs.org/patch/347024/ [2] https://github.com/torvalds/linux/commit/5072b7ba14de2b02b1d68f85dc5e81980e1818e7 [3] https://launchpad.net/ubuntu/+source/linux/3.13.0-1.16 [4] https://git.kernel.org/cgit/linux/kernel/git/benh/powerpc.git/?h=next [5] http://patchwork.ozlabs.org/patch/350461/ -- Mauricio Faria de Oliveira IBM Linux Technology Center -- 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/538268fe.1080...@linux.vnet.ibm.com
Re: [PATCH 5/7] ppc64el: kernel: patch: one patch for the PowerNV platform
On 05/25/2014 09:10 AM, Ben Hutchings wrote: On Sat, 2014-05-24 at 18:19 -0300, Mauricio Faria de Oliveira wrote: This patch didn't make mainline yet (3.15-rc6). This is required for booting in the PowerNV (non-virtualized) platform in little-endian mode. Sources: - https://github.com/torvalds/linux/commit/5072b7ba14de2b02b1d68f85dc5e81980e1818e7 - http://patchwork.ozlabs.org/patch/350461/ [...] Please put one of these URLs in the 'Origin' header of the added patch file. Ok, ack. If we have a better source (say, some -next tree) by the time I submit a PATCH V2 if needed, I'll put it there instead. Otherwise I'd stick w/ the other source than linus's github, since it was not pulled from there yet. Thanks, -- Mauricio Faria de Oliveira IBM Linux Technology Center -- 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/538269e3.9030...@linux.vnet.ibm.com
Re: [PATCH 2/7] ppc64el: kernel: config: little-endian powerpc64 options
On Sun, 2014-05-25 at 18:52 -0300, Mauricio Faria de Oliveira wrote: [...] +## +## file: drivers/net/ethernet/ibm/Kconfig +## +#. qemu-kvm with kernel only (no initrd). +CONFIG_IBMVETH=y qemu supports initrd. Oh, sure. I was too lazy to write a better comment, but the reason here is that specified in the patch header: just a convenience not to generate an initrd when we don't have a system yet (say, debootstrap --second-stage), and then booting it without using an initrd. That means, not to have to extract the deb package, and picking the ibmvscsi, ibmveth, blk_dev_sd, ext4_fs modules, plus shell, mount, insmod, other binaries; then creating the init script). Really, just a convenience. We can ship/tell people how to create a simple initrd for debootstrapping from other architectures. The thing with ppc64el is that it's usually not available for most people to start on, so that debootstrap --second-stage (for running in qemu-kvm, at least) is quite a common scenario nowadays. [...] Can you not run the second stage using qemu-ppc64le-static (or whatever it's called)? Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
