Bug#959472: initramfs-tools (0.137): E: /usr/share/initramfs-tools/hooks/plymouth failed
Package: initramfs-tools Version: 0.137 Severity: normal Dear Maintainer, update-initramfs fails: Processing triggers for initramfs-tools (0.137) ... update-initramfs: Generating /boot/initrd.img-5.2.17+ E: /usr/share/initramfs-tools/hooks/plymouth failed with return 1. update-initramfs: failed for /boot/initrd.img-5.2.17+ with 1. dpkg: error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1) Version 0.136 was okay. Regards, Dave Anglin -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 12M Apr 11 2015 /boot/initrd.img-3.12.40+ -rw-r--r-- 1 root root 11M Sep 27 2016 /boot/initrd.img-3.18.42+ -rw-r--r-- 1 root root 20M Apr 16 20:38 /boot/initrd.img-4.14.176+ -rw-r--r-- 1 root root 20M Apr 24 21:57 /boot/initrd.img-4.14.177+ -rw-r--r-- 1 root root 11M Aug 21 2016 /boot/initrd.img-4.4.19+ -rw-r--r-- 1 root root 12M Sep 22 2017 /boot/initrd.img-4.9.51+ -rw-r--r-- 1 root root 37M Aug 21 2019 /boot/initrd.img-5.2.0-2-parisc64 -rw-r--r-- 1 root root 20M Apr 24 19:43 /boot/initrd.img-5.2.17+ -rw-r--r-- 1 root root 20M Sep 17 2019 /boot/initrd.img-5.2.8+ -- /proc/cmdline root=LABEL=ROOT2 console=ttyS0 HOME=/ rootfstype=xfs clocksource=jiffies TERM=xterm palo_kernel=2/vmlinuz -- /proc/filesystems cramfs xfs ext2 ext3 ext4 -- lsmod Module Size Used by binfmt_misc13075 1 ext4 693225 3 ext2 113644 1 crc16 1655 1 ext4 jbd2 122319 1 ext4 mbcache 9772 2 ext4,ext2 sg 53216 0 ipmi_watchdog 25830 0 ipmi_si72878 1 ipmi_poweroff 12981 0 ipmi_devintf 14622 0 ipmi_msghandler60860 4 ipmi_devintf,ipmi_si,ipmi_watchdog,ipmi_poweroff nfsd 166379 11 ip_tables 26100 0 x_tables 35419 1 ip_tables ipv6 587774 146 autofs446898 2 xfs 1118276 2 libcrc32c 1618 1 xfs crc32c_generic 3086 7 raid10 80659 0 raid1 59399 0 raid0 13504 0 multipath 11251 0 linear 6392 0 md_mod222868 5 raid1,raid10,raid0,linear,multipath ses12759 0 enclosure 13195 1 ses scsi_transport_sas 46247 1 ses sd_mod 59912 10 sr_mod 24407 0 cdrom 44396 1 sr_mod uas24743 0 usb_storage76116 2 uas ata_generic 5378 0 ohci_pci5280 0 tg3 257464 0 pata_cmd64x10355 0 ptp20391 1 tg3 ohci_hcd 43731 1 ohci_pci ehci_pci5759 0 ehci_hcd 62336 1 ehci_pci sym53c8xx 111720 6 pps_core 13769 1 ptp libata282335 2 pata_cmd64x,ata_generic scsi_transport_spi 38311 1 sym53c8xx usbcore 270368 6 ohci_hcd,ehci_pci,usb_storage,ehci_hcd,ohci_pci,uas scsi_mod 247013 10 ses,scsi_transport_sas,sd_mod,scsi_transport_spi,usb_storage,uas,sym53c8xx,libata,sg,sr_mod usb_common 3118 1 usbcore -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = yes -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=auto KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto RUNSIZE=10% -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid10] unused devices: -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: dmsetup fsck fuse keymap klibc-utils kmod mdadm ntfs_3g plymouth resume thermal udev xfs zz-busybox -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 4.14.177+ (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages initramfs-tools depends on: ii initramfs-tools-core 0.137 ii linux-base4.6 initramfs-tools recommends no packages. Versions of packages initramfs-tools suggests: ii bash-completion 1:2.10-1 -- no debconf information
Bug#718270: linux: FTBFS on hppa: module mbcache.ko is in more than one package
Source: linux Version: 3.10.3-1 Severity: normal Build ends here with error: install -m 644 debian/linux-image-3.10-1-parisc/lib/modules/3.10-1-parisc/modules.builtin debian/linux-image-3.10-1-parisc/lib/modules/3.10-1-parisc/modules.order debian/kernel-image-3.10-1-parisc-di/lib/modules/3.10-1-parisc/ install -D -m 644 debian/linux-image-3.10-1-parisc/boot/System.map-3.10-1-parisc debian/kernel-image-3.10-1-parisc-di/boot/System.map-3.10-1-parisc kernel-wedge copy-modules 3.10-1 parisc 3.10-1-parisc kernel-wedge find-dups 3.10-1-parisc some modules are in more than one package debian/ext4-modules-3.10-1-parisc-di lib/modules/3.10-1-parisc/kernel/fs/mbcache.ko debian/ext3-modules-3.10-1-parisc-di lib/modules/3.10-1-parisc/kernel/fs/mbcache.ko command exited with status 1 make[2]: *** [install-udeb_hppa] Error 2 make[2]: Leaving directory `/mnt/debian/linux/linux-3.10.3' make[1]: *** [binary-arch_hppa] Error 2 make[1]: Leaving directory `/mnt/debian/linux/linux-3.10.3' make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Build command 'cd linux-3.10.3 dpkg-buildpackage -b -uc' failed. Fetched 76.5 MB in 41s (1,838 kB/s) -- System Information: Debian Release: 7.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 3.11.0-rc2+ (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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: http://lists.debian.org/blu0-smtp436d0bf5e4cbe26f7d540d97...@phx.gbl
Bug#718270: linux: FTBFS on hppa: module mbcache.ko is in more than one package
On 29-Jul-13, at 11:07 AM, Ben Hutchings wrote: Does this patch (applied with -p0) fix it? --- debian/installer/hppa/modules/hppa/core-modules (revision 0) +++ debian/installer/hppa/modules/hppa/core-modules (working copy) @@ -0,0 +1 @@ +#include core-modules --- END --- With the patch, the build completes successfully. On a different subject, could the build version of gcc be bumped from 4.4 to 4.7 or 4.8? Thanks for the quick response, Dave -- John David Anglin dave.ang...@bell.net -- 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/blu0-smtp26811ad399150e8c0c1fd897...@phx.gbl
Bug#622997: Debian bug 622997
On Sat, 2011-04-16 at 19:35 -0400, John David Anglin wrote: On Sat, 16 Apr 2011, James Bottomley wrote: Strike that one ... I enabled USB in my 2.6.39-rc3 build and it inserts the OHCI module and discovers the ports just fine. Boot 2.6.39-rc3 fails for me with attached config. I can't quite build it. With gcc version 4.2.4 (Debian 4.2.4-6) I'm getting an ICE: net/wireless/reg.c: In function 'freq_reg_info_regd': net/wireless/reg.c:645: internal compiler error: in expand_expr_real_1, at expr.c:8744 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.2/README.Bugs. make[2]: *** [net/wireless/reg.o] Error 1 This is probably fixed as it doesn't occur with gcc version 4.5.3 20110101 (prerelease) [gcc-4_5-branch revision 168387] (GCC) . GCC 4.2 and 4.3 are no longer maintained and there won't be any further releases from these branches. Without looking at the above, it's hard to tell whether the bug is a middle-end or backend bug. Many middle-end bugs are fixed in more recent GCC versions. Although newer versions may bring their own problems, we can get help in fixing problems particularly if they are regressions. The asm delay slot bug affected all GCC versions. I backported the fix to the 4.3, 4.4 and 4.5 branches. This is a problem in the kernel because of the following: ** The __asm__ op below simple prevents gcc/ld from reordering ** instructions across the mb() call. */ #define mb()__asm__ __volatile__(:::memory) /* barrier() */ It's just a matter of chance whether a barrier ends up in the delay slot of a branch in a critical location. Plus there's a bug in my kernel code: drivers/usb/host/xhci-pci.c: In function 'xhci_pci_setup': drivers/usb/host/xhci-pci.c:61: error: implicit declaration of function 'kzalloc If I correct for these (add missing slab.h include and disable wireless) I had to add missing slab.h as well. However, I didn't touch wireless with 4.5.3. and build, the last message I see is turn off boot console ttyB0 Which indicates it's got a problem with the console configuration (I don't see any console registration for the DIVA serial port on ttyS1 in the boot log). Comparing the console output that I recorded for the debian kernel, I see udev starts much earlier. It only has the initial message from the tg3 driver and SCSI subsystem. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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/20110417151147.326ec4...@hiauly1.hia.nrc.ca
Bug#622997: Debian bug 622997
On Sun, 17 Apr 2011, James Bottomley wrote: Comparing the console output that I recorded for the debian kernel, I see udev starts much earlier. It only has the initial message from the tg3 driver and SCSI subsystem. It's most likely a driver module that's getting loaded which is turned off in the booting configuration ... finding it isn't going to be easy, though ... Yup. I have reenabled IPV6 and USB and my system still boots. There are some nfs problems with IPV6 but that's probably a config issue. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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/20110417170635.ga23...@hiauly1.hia.nrc.ca
Bug#622997: Debian bug 622997
On Sun, 17 Apr 2011, James Bottomley wrote: On Sun, 2011-04-17 at 10:23 -0500, James Bottomley wrote: It's most likely a driver module that's getting loaded which is turned off in the booting configuration ... finding it isn't going to be easy, though ... Finally got a build (had to swap out -Os for -O2). Didn't need this with the gcc 4.5.3 snapshot that I mentioned previously. I traced the module loads and successful inits and found it; it's pata_cmd64x ... it loads but never returns from init. I bet it's trying to poke into ISA space which causes the HPMC. Removing this one module from the system allows it to boot again. Confirm that removing this module restores boot. This is excellent detective work. If I might ask, how did you trace the module loads and successful inits? Thanks, Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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/20110418012519.ga25...@hiauly1.hia.nrc.ca
Bug#622997: linux-image-2.6.38-2-parisc64-smp: Boot failure: PCI Errors in lba_pat_out8
Package: linux-2.6
Version: 2.6.38-2
Severity: critical
Justification: breaks the whole system
Booting...
Boot IO Dependent Code (IODC) revision 1
HARD Booted.
palo ipl 1.17 root@c3k Sun Mar 7 16:13:48 MST 2010
Skipping extended partition 6 - beyond reach of IPL
Partition Start(MB) End(MB) Id Type
1 1 31 f0 Palo
2 32 156 83 ext2
5 1576832 83 ext2
PALO(F0) partition contains:
0/vmlinux64 6241289 bytes @ 0x48000
Command line for kernel: 'root=/dev/sda5 console=ttyS1 HOME=/
palo_kernel=2/vmlinux'
Selected kernel: /vmlinux from partition 2
Selected ramdisk: /initrd.img from partition 2
ELF64 executable
Entry 0010 first 0010 n 3
Segment 0 load 0010 size 5419008 mediaptr 0x1000
Segment 1 load 006b9ce0 size 507616 mediaptr 0x52cce0
Segment 2 load 00738000 size 323008 mediaptr 0x5a9000
Loading ramdisk 14508363 bytes @ 3f218000...
Branching to kernel entry point 0x0010. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.38-2-parisc64-smp (Debian 2.6.38-2)
(b...@decadent.org.uk) (gcc version 4.4.5 (GCC) ) #1 SMP Wed Mar 30 08:16:31
UTC 2011
[0.00] unwind_init: start = 0x4053f000, end = 0x405728a0, entries =
13194
[0.00] FP[0] enabled: Rev 1 Model 20
[0.00] The 64-bit Kernel has started...
[0.00] bootconsole [ttyB0] enabled
[0.00] Initialized PDC Console for debugging.
[0.00] Determining PDC firmware type: 64 bit PAT.
[0.00] model 8870 0491 0002 3e0505e7352af711
10f0 0008 00b2 00b2
[0.00] vers 0301
[0.00] CPUID vers 20 rev 4 (0x0284)
[0.00] capabilities 0x35
[0.00] model 9000/800/rp3440
[0.00] parisc_cache_init: Only equivalent aliasing supported!
[0.00] Memory Ranges:
[0.00] 0) Start 0x End 0x3fff Size 1024
MB
[0.00] 1) Start 0x0001 End 0x00027fdf Size 6142
MB
[0.00] 2) Start 0x00404000 End 0x0040 Size 3072
MB
[0.00] Total Memory: 10238 MB
[0.00] initrd: 7f218000-7ffee14b
[0.00] initrd: reserving 3f218000-3ffee14b (mem_max 27fe0)
[0.00] PERCPU: Embedded 10 pages/cpu @428f5000 s11712 r8192
d21056 u40960
[0.00] SMP: bootstrap CPU ID is 0
[0.00] Built 3 zonelists in Zone order, mobility grouping on. Total
pages: 2585095
[0.00] Kernel command line: root=/dev/sda5 console=ttyS1 HOME=/
palo_kernel=2/vmlinux
[0.00] PID hash table entries: 4096 (order: 3, 32768 bytes)
[0.00] Dentry cache hash table entries: 2097152 (order: 12, 16777216
bytes)
[0.00] Inode-cache hash table entries: 1048576 (order: 11, 8388608
bytes)
[0.00] Memory: 10273764k/10483712k available (3590k kernel code,
209948k reserved, 1649k data, 316k init)
[0.00] virtual kernel memory layout:
[0.00] vmalloc : 0x8000 - 0x3f00 (1007 MB)
[0.00] memory : 0x4000 - 0x00414000 (266240
MB)
[0.00] .init : 0x40738000 - 0x40787000 ( 316 kB)
[0.00] .data : 0x40481b60 - 0x4061e020 (1649 kB)
[0.00] .text : 0x4010 - 0x40481b60 (3590 kB)
[0.00] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=8,
Nodes=8
[0.00] Hierarchical RCU implementation.
[0.00] CONFIG_RCU_FANOUT set to non-default value of 32
[0.00] RCU-based detection of stalled CPUs is disabled.
[0.00] NR_IRQS:128
[0.00] Console: colour dummy device 160x64
[0.00] Calibrating delay loop... 1597.44 BogoMIPS (lpj=3194880)
[0.096000] pid_max: default: 32768 minimum: 301
[0.096000] Security Framework initialized
[0.096000] SELinux: Disabled at boot.
[0.096000] Mount-cache hash table entries: 256
[0.104000] Initializing cgroup subsys ns
[0.104000] ns_cgroup deprecated: consider using the 'clone_children' flag
without the ns_cgroup.
[0.108000] Initializing cgroup subsys cpuacct
[0.108000] Initializing cgroup subsys devices
[0.116000] Initializing cgroup subsys freezer
[0.116000] Initializing cgroup subsys net_cls
[0.124000] Initializing cgroup subsys blkio
[0.124000] Brought up 1 CPUs
[0.124000] devtmpfs: initialized
[0.132000] print_constraints: dummy:
[0.132000] NET: Registered protocol family 16
[0.14] EISA bus registered
[0.14] Searching for devices...
[0.26] Found devices:
[0.26] 1. Storm Peak Slow at 0xfe78 [128] { 0, 0x0, 0x887,
0x4 }
[0.264000] 2. Storm Peak Slow at
Bug#622997: Debian bug 622997
I posted this debian bug report because the most recent debian SMP kernel build fails to boot on my rp3440: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622997 I don't think debian kernels have worked since lenny. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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/20110416180754.ga18...@hiauly1.hia.nrc.ca
Bug#622997: Debian bug 622997
On Sat, 2011-04-16 at 14:07 -0400, John David Anglin wrote: I posted this debian bug report because the most recent debian SMP kernel build fails to boot on my rp3440: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622997 I don't think debian kernels have worked since lenny. Hmm, well upstream ones have: so it's likely a patch debian has but upstream doesn't, or it could be a toolchain issue ... I didn't think gcc-4.4.5 worked properly on 64 bit without a few patches? Yes, but debian tends to build almost everything. For some reason, I've turned off ipv6. Unlike many kernel bugs, this one is completely reproducible. I would say gcc-4.4.6 or a snapshot latter than 2010-12-22 is needed for kernel builds. asm in delay slot patch is key patch. As this was discussed on list, I'm a bit surprised that this wasn't picked up if that's the problem. I'm doing a build based on debian's config with my toolchain to see if it has the same problem. There may be a toolchain issue wrt CONFIG_FRAME_POINTER (frame pointer optimization). Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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/20110416192920.1e15b4...@hiauly1.hia.nrc.ca
Bug#622997: Debian bug 622997
On Sat, 16 Apr 2011, Ben Hutchings wrote: If you can identify the compiler patches required, I can ask the Debian gcc maintainers to apply them. gcc-4.4.6 is released and contains all parisc patches known to be relevant. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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/20110417025055.ga20...@hiauly1.hia.nrc.ca
Bug#561203: threads and fork on machine with VIPT-WB cache
On Wed, 02 Jun 2010, Modestas Vainius wrote: Hello, this bug [1] is back to the very common department with eglibc 2.11 (libc6- dev_2.11.1-1) builds. Majority of KDE applications are failing to build on hppa again. Is there really nothing what could be done to fix it? I will just say it is very tricky. I think a fix is possible (arm and mips had similar cache problems) but the victim replacement present in PA8800/PA8900 caches makes the problem especially difficult for hardware using these processors. I have spent the last few months testing various alternatives and have now done hundreds of kernel builds. I did post some experimental patches that fix the problem on UP kernels. However, the problem is not resolved for SMP kernels. The minifail test is a good one to demonstrate the problem. Indeed, a very similar test was given in the thread below: http://readlist.com/lists/vger.kernel.org/linux-kernel/54/270861.html This thread also discusses the PA8800 problem: http://readlist.com/lists/vger.kernel.org/linux-kernel/54/271417.html I currently surmise that we have a problem with the cache victim replacement, although the cause isn't clear. I did find recently that the cache prefetch in copy_user_page_asm extends to the line beyond the end of the page, but fixing this doesn't resolve the problem. I am still experimenting with using equivalent aliasing. It does help to flush in ptep_set_wrprotect. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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/20100602171600.ga5...@hiauly1.hia.nrc.ca
Bug#561203: threads and fork on machine with VIPT-WB cache
On Thu, 08 Apr 2010, Helge Deller wrote: I tested your patch today on one of my machines with plain kernel 2.6.33 (32bit, SMP, B2000 I think). Sadly I still did see the minifail bug. Are you sure, that the patch fixed this bug for you? Seemed to, but I have a bunch of other changes installed. Possibly, the change to cacheflush.h is important. It affects all PA8000. I also think the change suggested by James + if (pte_dirty(old_pte)) is important for SMP. With the patch set that I sent, my rp3440 and gsyprf11 seem reasonably stable running 2.6.33.2 SMP. I doubt all problems are solved but things are a lot better than before. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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/20100408224446.96f294...@hiauly1.hia.nrc.ca
Bug#561203: threads and fork on machine with VIPT-WB cache
Thanks a lot for the discussion.
James Bottomley wrote:
So your theory is that the data the kernel sees doing the page copy can
be stale because of dirty cache lines in userspace (which is certainly
possible in the ordinary way)?
Yes.
By design that shouldn't happen: the idea behind COW breaking is
that before it breaks, the page is read only ... this means that
processes can have clean cache copies of it, but never dirty cache
copies (because writes are forbidden).
That must be design, I agree.
To keep this condition (no dirty cache for COW page), we need to flush
cache before ptep_set_wrprotect. That's my point.
Please look at the code path:
(kernel/fork.c)
do_fork - copy_process - copy_mm - dup_mm - dup_mmap -
(mm/memory.c)
copy_page_range - copy_p*d_range - copy_one_pte - ptep_set_wrprotect
The function flush_cache_dup_mm is called from dup_mmap, that's enough
for a case of a process with single thread.
I think that:
We need to flush cache before ptep_set_wrprotect for a process with
multiple threads. Other threads may change memory after a thread
invokes do_fork and before calling ptep_set_wrprotect. Specifically,
a process may sleep at pte_alloc function to get a page.
I agree. It is interesting that in the case of the Debian bug that
a thread of the parent process causes the COW break and thereby corrupts
its own memory. As far as I can tell, the fork'd child never writes
to the memory that causes the fault.
My testing indicates that your suggested change fixes the Debian
bug. I've attached below my latest test version. This seems to fix
the bug on both SMP and UP kernels.
However, it doesn't fix all page/cache related issues on parisc
SMP kernels that I commonly see.
My first inclination after even before reading your analysis was
to assume that copy_user_page was broken (i.e, that even if a
processor cache was dirty when the COW page was write protected,
it should be possible to do the flush before the page is copied).
However, this didn't seem to work... Possibly, there are issues
with aliased addresses.
I note that sparc flushes the entire cache and purges the entire
tlb in kmap_atomic/kunmap_atomic for highmem. Although the breakage
that I see is not limited to PA8800/PA8900, I'm not convinced
that we maintain coherency that is required for these processors
in copy_user_page when we have multiple threads.
As a side note, kmap_atomic/kunmap_atomic seem to lack calls to
pagefault_disable()/pagefault_enable() on PA8800.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
diff --git a/arch/parisc/include/asm/pgtable.h
b/arch/parisc/include/asm/pgtable.h
index a27d2e2..b140d5c 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -14,6 +14,7 @@
#include linux/bitops.h
#include asm/processor.h
#include asm/cache.h
+extern void flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr,
unsigned long pfn);
/*
* kern_addr_valid(ADDR) tests if ADDR is pointing to valid kernel
@@ -456,17 +457,22 @@ static inline pte_t ptep_get_and_clear(struct mm_struct
*mm, unsigned long addr,
return old_pte;
}
-static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long
addr, pte_t *ptep)
+static inline void ptep_set_wrprotect(struct vm_area_struct *vma, struct
mm_struct *mm, unsigned long addr, pte_t *ptep)
{
#ifdef CONFIG_SMP
unsigned long new, old;
+#endif
+ pte_t old_pte = *ptep;
+
+ if (atomic_read(mm-mm_users) 1)
+ flush_cache_page(vma, addr, pte_pfn(old_pte));
+#ifdef CONFIG_SMP
do {
old = pte_val(*ptep);
new = pte_val(pte_wrprotect(__pte (old)));
} while (cmpxchg((unsigned long *) ptep, old, new) != old);
#else
- pte_t old_pte = *ptep;
set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
#endif
}
diff --git a/mm/memory.c b/mm/memory.c
index 09e4b1b..21c2916 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -616,7 +616,7 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct
*src_mm,
* in the parent and the child
*/
if (is_cow_mapping(vm_flags)) {
- ptep_set_wrprotect(src_mm, addr, src_pte);
+ ptep_set_wrprotect(vma, src_mm, addr, src_pte);
pte = pte_wrprotect(pte);
}
--
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/20100405025154.de1d55...@hiauly1.hia.nrc.ca
Bug#561203: threads and fork on machine with VIPT-WB cache
By design that shouldn't happen: the idea behind COW breaking is that before it breaks, the page is read only ... this means that processes can have clean cache copies of it, but never dirty cache copies (because writes are forbidden). That must be design, I agree. To keep this condition (no dirty cache for COW page), we need to flush cache before ptep_set_wrprotect. That's my point. Is it possible that a sleep/reschedule could cause the cache to become dirty again before it is write protected? Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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/20100405025840.b79a54...@hiauly1.hia.nrc.ca
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Fri, 31 Jul 2009, Carlos O'Donell wrote: + if (d = 15) + stub-insns[0] |= reassemble_14(d); reassemble_14 is wrong for ldd format 3. Need format 5 and im5 insertion. This is using reassemble_14 for ldd format 5, which is correct. Huh? Format 5 has a five bit immediate and it's not compatible with reassemble_14. The value is actually being stuffed into a format 3 ldd pattern (i.e., format 3 is being used for displacements 0 and 8). If format 3 is going to be used for short displacements, then use reassemble_16a as it is the inverse to the assemble_16a operation described in the arch. Using reassemble_14 with ldd is confusing. As you pointed out, the arch shows using format 5 for short displacements. It's unclear whether there is a performance or functional difference aside from the behavior of space selection. There may be no requirement for hardware to implement short displacements using format 3. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
case ELF_STUB_GOT:
- stub-insns[0] = 0x537b;/* ldd 0(%dp),%dp */
+ stub-insns[0] = 0x537b;/* ldd 0(%dp),%dp */
stub-insns[1] = 0x53610020;/* ldd 10(%dp),%r1 */
stub-insns[2] = 0xe820d000;/* bve (%r1)*/
stub-insns[3] = 0x537b0030;/* ldd 18(%dp),%dp */
- stub-insns[0] |= reassemble_14(get_got(me, value, addend)
0x3fff);
+ d = get_got(me, value, addend);
+ if (d = 15)
+ stub-insns[0] |= reassemble_14(d);
reassemble_14 is wrong for ldd format 3. Need format 5 and im5 insertion.
Since I complained about not using format 5 for small displacements,
here's an updated patch for review. Seems to work:
d...@mx3210:/usr/src/D$ lsmod
Module Size Used by
dm_snapshot45680 0
dm_mirror 27480 0
dm_region_hash 17408 1 dm_mirror
dm_log 18968 2 dm_mirror,dm_region_hash
dm_mod111200 3 dm_snapshot,dm_mirror,dm_log
ext2 99648 2
sd_mod 63792 4
crc_t10dif 2368 1 sd_mod
tg3 196428 0
sym53c8xx 127568 3
libphy 39280 1 tg3
scsi_transport_spi 43528 1 sym53c8xx
scsi_mod 261104 3 sd_mod,sym53c8xx,scsi_transport_spi
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Signed-off-by: John David Anglin dave.ang...@nrc-cnrc.gc.ca
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ecd1c50..88989cb 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -86,8 +86,12 @@
* the bottom of the table, which has a maximum signed displacement of
* 0x3fff; however, since we're only going forward, this becomes
* 0x1fff, and thus, since each GOT entry is 8 bytes long we can have
- * at most 1023 entries */
-#define MAX_GOTS 1023
+ * at most 1023 entries.
+ * To overcome this 14bit displacement with some kernel modules, we'll
+ * use instead the unusal 16bit displacement method (see reassemble_16a)
+ * which gives us a maximum positive displacement of 0x7fff, and as such
+ * allows us to allocate up to 4095 GOT entries. */
+#define MAX_GOTS 4095
/* three functions to determine where in the module core
* or init pieces the location is */
@@ -145,12 +149,40 @@ struct stub_entry {
/* The reassemble_* functions prepare an immediate value for
insertion into an opcode. pa-risc uses all sorts of weird bitfields
in the instruction to hold the value. */
+static inline int sign_unext (int x, int len)
+{
+ int len_ones;
+
+ len_ones = (1 len) - 1;
+ return x len_ones;
+}
+
+static inline int low_sign_unext(int x, int len)
+{
+ int sign, temp;
+
+ sign = (x (len-1)) 1;
+ temp = sign_unext (x, len-1);
+ return (temp 1) | sign;
+}
+
static inline int reassemble_14(int as14)
{
return (((as14 0x1fff) 1) |
((as14 0x2000) 13));
}
+static inline int reassemble_16a(int as16)
+{
+ int s, t;
+
+ /* Unusual 16-bit encoding, for wide mode only. */
+ t = (as16 1) 0x;
+ s = (as16 0x8000);
+ return (t ^ s ^ (s 1)) | (s 15);
+}
+
+
static inline int reassemble_17(int as17)
{
return (((as17 0x1) 16) |
@@ -409,6 +441,7 @@ static Elf_Addr get_stub(struct module *me, unsigned long
value, long addend,
enum elf_stub_type stub_type, Elf_Addr loc0, unsigned int targetsec)
{
struct stub_entry *stub;
+ int d;
/* initialize stub_offset to point in front of the section */
if (!me-arch.section[targetsec].stub_offset) {
@@ -462,12 +495,19 @@ static Elf_Addr get_stub(struct module *me, unsigned long
value, long addend,
*/
switch (stub_type) {
case ELF_STUB_GOT:
- stub-insns[0] = 0x537b;/* ldd 0(%dp),%dp */
+ d = get_got(me, value, addend);
+ if (d = 15) {
+ /* Format 5 */
+ stub-insns[0] = 0x0f6010db; /* ldd 0(%dp),%dp */
+ stub-insns[0] |= low_sign_unext(d, 5) 16;
+ } else {
+ /* Format 3 */
+ stub-insns[0] = 0x537b; /* ldd 0(%dp),%dp */
+ stub-insns[0] |= reassemble_16a(d);
+ }
stub-insns[1] = 0x53610020;/* ldd 10(%dp),%r1 */
stub-insns[2] = 0xe820d000;/* bve (%r1)*/
stub-insns[3] = 0x537b0030;/* ldd 18(%dp),%dp */
-
- stub-insns[0] |= reassemble_14(get_got(me, value, addend)
0x3fff);
break;
case ELF_STUB_MILLI:
stub-insns[0] = 0x2020
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Fri, Jul 31, 2009 at 5:17 AM, Frans Popelen...@planet.nl wrote: Affects both stable and unstable! kernel: Linux version 2.6.26-2-parisc64-smp [...] kernel: nfs: Global Offset Table overflow (used 1075, allowed 1023) kernel: Linux version 2.6.30-1-parisc64 [...] kernel: nfs: Global Offset Table overflow (used 1164, allowed 1023) The error comes from arch/parisc/kernel/module.c. Looks like it is a known issue: http://lists.parisc-linux.org/pipermail/parisc-linux/2006-October/054826.html I've seen the same problem. Sent a message to the parisc-linux list about this recently. Only 32-bit targets have the 14-bit signed immediate offset (0x3fff), which becomes a 13-bit limit when loading positive offsets e.g. +0x1fff or 1023 GOT slots. Can't we offset the table and double the number of entries? Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
case ELF_STUB_GOT: - stub-insns[0] = 0x537b;/* ldd 0(%dp),%dp */ + stub-insns[0] = 0x537b;/* ldd 0(%dp),%dp */ stub-insns[1] = 0x53610020;/* ldd 10(%dp),%r1 */ stub-insns[2] = 0xe820d000;/* bve (%r1)*/ stub-insns[3] = 0x537b0030;/* ldd 18(%dp),%dp */ - stub-insns[0] |= reassemble_14(get_got(me, value, addend) 0x3fff); + d = get_got(me, value, addend); + if (d = 15) + stub-insns[0] |= reassemble_14(d); reassemble_14 is wrong for ldd format 3. Need format 5 and im5 insertion. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
case ELF_STUB_GOT: - stub-insns[0] = 0x537b;/* ldd 0(%dp),%dp */ + stub-insns[0] = 0x537b;/* ldd 0(%dp),%dp */ stub-insns[1] = 0x53610020;/* ldd 10(%dp),%r1 */ stub-insns[2] = 0xe820d000;/* bve (%r1)*/ stub-insns[3] = 0x537b0030;/* ldd 18(%dp),%dp */ - stub-insns[0] |= reassemble_14(get_got(me, value, addend) 0x3fff); + d = get_got(me, value, addend); + if (d = 15) + stub-insns[0] |= reassemble_14(d); reassemble_14 is wrong for ldd format 3. Need format 5 and im5 insertion. The format 5 version of ldd 0(%dp),%dp is 0x0f6010db. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian parisc config for 2.6.26 broke the real time clock
Um, because the architecture doesn't have an i2c bus. Don't know about rtc but some PA-RISC models definitely have an i2c bus. I see this message on a A500-75 model: The support bus which connects the system processors, the Guardian Service Processor (GSP) and the Power Monitor or Platform Monitor may have become hung. (The support bus can be tested by issuing the GSP command XD, and selecting the I2C access test). Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian parisc config for 2.6.26 broke the real time clock
This I2C bus is not acessible by the operating system (as far as I know). HP-UX seems to be able to access fan and power status somehow. It sends me an email when it thinks the i2c is hung, and once a day, it sends a message that a fan which the chassis doesn't have (as far as I can tell) has failed. Of course, the A500-75 model doesn't actually exist... The model that actually shipped was a A500-7X. As a result, I've never been able to update the firmware. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: 2.6.14 has been released,
On Fri, Oct 28, 2005 at 05:34:06PM +0900, Horms wrote: Also, can someone look into HPPA, or point me at which patch to use? http://packages.vergenet.net/testing/linux-2.6-2.6.14/linux-2.6_2.6.14-1-hppa.log.gz I know I *said* not to use the -pa0 kernel, but it's booted fine for me on a K460 and an N4000. Any other reports? Not -pa0 but 2.6.14-rc5-pa1 has been up for more than 7 days now on my c3k. Nothing since 2.6.8.1-pa11 has been this stable. However, gsyprf11 with 64-bit SMP hasn't been as stable (two crashes doing GCC builds and checks in roughly the same period). Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
