Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
Package: linux-2.6
Version: 2.6.30-3
Severity: important
The 2.6.30-1-parisc64-smp kernel fails to boot on my J5600 system.
The non-smp kernel does boot correctly and the oops also indicates
an smp problem.
Boot log from serial console attached.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: hppa (parisc64)
Kernel: Linux 2.6.30-1-parisc64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Command line for kernel: 'root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102
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 4771840 mediaptr 0x1000
Segment 1 load 00618000 size 460792 mediaptr 0x48e000
Segment 2 load 0068c000 size 300800 mediaptr 0x4ff000
Loading ramdisk 8182144 bytes @ 3f821000...
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.30-1-parisc64-smp (Debian 2.6.30-3)
(wa...@debian.org) (gcc version 4.3.3 (GCC) ) #1 SMP Sun Jul 19 10:34:15 UTC
2009
[0.00] unwind_init: start = 0x404b9144, end = 0x404e5204, entries =
11276
[0.00] WARNING: Out of order unwind entry! 404bb0c4 and
404bb0d4
[0.00] WARNING: Out of order unwind entry! 404bb0d4 and
404bb0e4
[0.00] FP[0] enabled: Rev 1 Model 16
[0.00] The 64-bit Kernel has started...
[0.00] console [ttyB0] enabled
[0.00] Initialized PDC Console for debugging.
[0.00] Determining PDC firmware type: System Map.
[0.00] model 5d10 0491 0002 778fe5fc 10f0
0008 00b2 00b2
[0.00] vers 0300
[0.00] CPUID vers 17 rev 10 (0x022a)
[0.00] capabilities 0x3
[0.00] model 9000/785/J5600
[0.00] Total Memory: 2048 MB
[0.00] initrd: 7f821000-7ffee980
[0.00] initrd: reserving 3f821000-3ffee980 (mem_max 8000)
[0.00] LCD display at fff0f05d0008,fff0f05d registered
[0.00] SMP: bootstrap CPU ID is 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 517120
[0.00] Kernel command line: root=/dev/sda5 HOME=/ console=ttyS0
TERM=vt102 palo_kernel=2/vmlinux
[0.00] NR_IRQS:128
[0.00] PID hash table entries: 4096 (order: 12, 32768 bytes)
[0.00] Console: colour dummy device 160x64
[0.064000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[0.168000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[0.52] Memory: 2046464k/2097152k available (3144k kernel code, 50140k
reserved, 1467k data, 296k init)
[0.648000] virtual kernel memory layout:
[0.648000] vmalloc : 0x8000 - 0x3f00 (1007 MB)
[0.648000] memory : 0x4000 - 0xc000 (2048 MB)
[0.648000] .init : 0x4068c000 - 0x406d6000 ( 296 kB)
[0.648000] .data : 0x40412078 - 0x40581000 (1467 kB)
[0.648000] .text : 0x4010 - 0x40412078 (3144 kB)
[1.172000] Calibrating delay loop... 1101.82 BogoMIPS (lpj=2203648)
[1.352000] Security Framework initialized
[1.404000] SELinux: Disabled at boot.
[1.456000] Mount-cache hash table entries: 256
[1.516000] Initializing cgroup subsys ns
[1.568000] Initializing cgroup subsys cpuacct
[1.628000] Initializing cgroup subsys devices
[1.684000] Initializing cgroup subsys freezer
[1.744000] Initializing cgroup subsys net_cls
[1.804000] Brought up 1 CPUs
[1.844000] net_namespace: 1928 bytes
[1.892000] regulator: core version 0.5
[1.944000] NET: Registered protocol family 16
[2.004000] EISA bus registered
[2.044000] Searching for devices...
[2.336000] Found devices:
[2.372000] 1. Astro BC Runway Port at 0xfed0 [10] { 12, 0x0,
0x582, 0xb }
[2.48] 2. Elroy PCI Bridge at 0xfed3 [10/0] { 13, 0x0,
0x782, 0xa }
[2.588000] 3. Elroy PCI Bridge at 0xfed32000 [10/1] { 13, 0x0,
0x782, 0xa }
[2.692000] 4. Elroy PCI Bridge at 0xfed34000 [10/2] { 13, 0x0,
0x782, 0xa }
[2.80] 5. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0,
0x782, 0xa }
[2.908000] 6. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0,
0x782, 0xa }
[3.012000] 7. Forte W+ 2w at 0xfffa [32] { 0, 0x0, 0x5d1,
0x4 }
[3.112000] 8. Forte W+ 2w at 0xfffa2000 [34] { 0, 0x0, 0x5d1,
0x4 }
[3.208000] 9. Memory at
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
* Frans Pop elen...@planet.nl [2009-07-31 08:17]:
The 2.6.30-1-parisc64-smp kernel fails to boot on my J5600 system.
The non-smp kernel does boot correctly and the oops also indicates
an smp problem.
Copying debian-h...@lists.debian.org...
Boot log from serial console attached.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: hppa (parisc64)
Kernel: Linux 2.6.30-1-parisc64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Command line for kernel: 'root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102
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 4771840 mediaptr 0x1000
Segment 1 load 00618000 size 460792 mediaptr 0x48e000
Segment 2 load 0068c000 size 300800 mediaptr 0x4ff000
Loading ramdisk 8182144 bytes @ 3f821000...
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.30-1-parisc64-smp (Debian 2.6.30-3)
(wa...@debian.org) (gcc version 4.3.3 (GCC) ) #1 SMP Sun Jul 19 10:34:15 UTC
2009
[0.00] unwind_init: start = 0x404b9144, end = 0x404e5204, entries =
11276
[0.00] WARNING: Out of order unwind entry! 404bb0c4 and
404bb0d4
[0.00] WARNING: Out of order unwind entry! 404bb0d4 and
404bb0e4
[0.00] FP[0] enabled: Rev 1 Model 16
[0.00] The 64-bit Kernel has started...
[0.00] console [ttyB0] enabled
[0.00] Initialized PDC Console for debugging.
[0.00] Determining PDC firmware type: System Map.
[0.00] model 5d10 0491 0002 778fe5fc 10f0
0008 00b2 00b2
[0.00] vers 0300
[0.00] CPUID vers 17 rev 10 (0x022a)
[0.00] capabilities 0x3
[0.00] model 9000/785/J5600
[0.00] Total Memory: 2048 MB
[0.00] initrd: 7f821000-7ffee980
[0.00] initrd: reserving 3f821000-3ffee980 (mem_max 8000)
[0.00] LCD display at fff0f05d0008,fff0f05d registered
[0.00] SMP: bootstrap CPU ID is 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 517120
[0.00] Kernel command line: root=/dev/sda5 HOME=/ console=ttyS0
TERM=vt102 palo_kernel=2/vmlinux
[0.00] NR_IRQS:128
[0.00] PID hash table entries: 4096 (order: 12, 32768 bytes)
[0.00] Console: colour dummy device 160x64
[0.064000] Dentry cache hash table entries: 262144 (order: 9, 2097152
bytes)
[0.168000] Inode-cache hash table entries: 131072 (order: 8, 1048576
bytes)
[0.52] Memory: 2046464k/2097152k available (3144k kernel code, 50140k
reserved, 1467k data, 296k init)
[0.648000] virtual kernel memory layout:
[0.648000] vmalloc : 0x8000 - 0x3f00 (1007
MB)
[0.648000] memory : 0x4000 - 0xc000 (2048
MB)
[0.648000] .init : 0x4068c000 - 0x406d6000 ( 296
kB)
[0.648000] .data : 0x40412078 - 0x40581000 (1467
kB)
[0.648000] .text : 0x4010 - 0x40412078 (3144
kB)
[1.172000] Calibrating delay loop... 1101.82 BogoMIPS (lpj=2203648)
[1.352000] Security Framework initialized
[1.404000] SELinux: Disabled at boot.
[1.456000] Mount-cache hash table entries: 256
[1.516000] Initializing cgroup subsys ns
[1.568000] Initializing cgroup subsys cpuacct
[1.628000] Initializing cgroup subsys devices
[1.684000] Initializing cgroup subsys freezer
[1.744000] Initializing cgroup subsys net_cls
[1.804000] Brought up 1 CPUs
[1.844000] net_namespace: 1928 bytes
[1.892000] regulator: core version 0.5
[1.944000] NET: Registered protocol family 16
[2.004000] EISA bus registered
[2.044000] Searching for devices...
[2.336000] Found devices:
[2.372000] 1. Astro BC Runway Port at 0xfed0 [10] { 12, 0x0,
0x582, 0xb }
[2.48] 2. Elroy PCI Bridge at 0xfed3 [10/0] { 13, 0x0,
0x782, 0xa }
[2.588000] 3. Elroy PCI Bridge at 0xfed32000 [10/1] { 13, 0x0,
0x782, 0xa }
[2.692000] 4. Elroy PCI Bridge at 0xfed34000 [10/2] { 13, 0x0,
0x782, 0xa }
[2.80] 5. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0,
0x782, 0xa }
[2.908000] 6. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0,
0x782, 0xa }
[3.012000] 7. Forte W+ 2w at 0xfffa [32] { 0,
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
Hmm. The Badness at smp.c warning isn't new of course. That was also there with .24 and .26 (the last working kernel I have). What is new is that the boot now hangs immediately after that point. I also note the following in the boot messages: unwind_init: start = 0x404b9144, end = 0x404e5204, entries = 11276 WARNING: Out of order unwind entry! 404bb0c4 and 404bb0d4 WARNING: Out of order unwind entry! 404bb0d4 and 404bb0e4 But those were also present in .26 (though later in the boot). What's very strange is that for the .30-smp boot the following block is missing: On node 0 totalpages: 524288 Normal zone: 7168 pages used for memmap Normal zone: 0 pages reserved Normal zone: 517120 pages, LIFO batch:31 Movable zone: 0 pages used for memmap Especially as it is present in both .26-smp, but also in .30-up. Attached, for comparison, boot logs for .24-smp, .26-smp, .30-smp and .30-up. If needed I can build kernels for intermediate versions between .26 and .30. Cheers, FJP boot-logs.tgz Description: application/tgz
Processed: Re: Bug#539378: Acknowledgement ([hppa]: fails to load nfs module: Global Offset Table overflow)
Processing commands for cont...@bugs.debian.org: found 539378 2.6.30-3 Bug #539378 [linux-2.6] [hppa]: fails to load nfs module: Global Offset Table overflow There is no source info for the package 'linux-2.6' at version '2.6.30-3' with architecture '' Unable to make a source version for version '2.6.30-3' Bug Marked as found in versions 2.6.30-3. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: tagging 536426
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny3 tags 536426 + pending Bug #536426 [linux-2.6] linux-image: CIFS in 2.6.30 may get EEXIST on temp file create causing file creation flood Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535331: Can anyone please explain why 'lilo' was removed from linux-image-*.postinst?
The issue is this difference: --- /var/lib/dpkg/info/linux-image-2.6.18-6-686.postinst2009-05-05 07:43:48.0 +0200 +++ /var/lib/dpkg/info/linux-image-2.6.24-etchnhalf.1-686.postinst 2009-07-27 06:37:00.0 +0200 @@ -25,7 +25,7 @@ $|=1; # Predefined values: -my $version = 2.6.18-6-686; +my $version = 2.6.24-etchnhalf.1-686; my $link_in_boot = ; # Should be empty, mostly my $no_symlink= ; # Should be empty, mostly my $reverse_symlink = ; # Should be empty, mostly @@ -34,8 +34,8 @@ my $do_bootfloppy = Yes; # target machine defined my $do_bootloader = Yes; # target machine defined my $move_image= ''; # target machine defined -my $kimage= bzImage; # Should be empty, mostly -my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo +my $kimage= ; # Should be empty, mostly +my $loader= ; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo my $image_dir = /boot;# where the image is located my $clobber_modules = ''; # target machine defined my $relative_links= ; # target machine defined The $loader change prevents lilo from being automatically run after installing the image. I've been running into this problem for a while, and until now just made one of the two workarounds I suspect most users choose: a) replace lilo with grub b) run lilo manually after installing a new linux-image I do however manage a few servers where installing grub has been considered too risky at the moment (due to no-way-out-if-it-blows-up). So they still have lilo. However, running lilo is also risky with the newer kernel images due to this bug. Security updates may overwrite the lilo default image, causing a boot failure unless lilo is run manually first. I only have serial console access to these servers, so that means a dead server until I can arrange physical access (which is why I can't just install grub either). This makes the bug serious to me. Now, to stop whining and start working: I have tried to find the answer to the question in the subject, but have found nothing. Which suggests that the bug is just a mere accident when the build system was changed somewhere between the 2.6.18 and 2.6.24 etch images. It would be very nice if someone from the kernel team could verify that, and if the attached patch could be considered. The patch is made against the 2.6.24-etchnhalf.1 source, but does also apply to the 2.6.26-2 source. Please let me know if I should provide it in some other way. The point is that it needs to be applied to the current etch and lenny builds. Please note that similar bug reports seem to have been pushed back and forth between linux-image-* and lilo for a while. See e.g. bug #342542. Removing lilo is of course also an option for future releases, but it won't fix the bug wrt the etch and lenny linux-images. Bjørn --- linux-2.6.24-2.6.24/debian/rules.real.orig 2009-07-31 12:07:59.0 +0200 +++ linux-2.6.24-2.6.24/debian/rules.real 2009-07-31 12:57:04.0 +0200 @@ -403,6 +403,9 @@ install-image_powerpc_$(FEATURESET)_$(FLAVOUR)_plain_templates: ARG_KIMAGE = vmlinux +install-image_amd64_$(FEATURESET)_$(FLAVOUR)_plain_templates \ +install-image_i386_$(FEATURESET)_$(FLAVOUR)_plain_templates: ARG_BOOTLOADER = lilo + install-image_s390_$(FEATURESET)_$(FLAVOUR)_plain_templates: ARG_BOOTLOADER = zipl install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_templates:
Bug#535331: Can anyone please explain why 'lilo' was removed from linux-image-*.postinst?
On Fri, Jul 31, 2009 at 01:35:59PM +0200, Bjørn Mork wrote: The issue is this difference: --- /var/lib/dpkg/info/linux-image-2.6.18-6-686.postinst2009-05-05 07:43:48.0 +0200 +++ /var/lib/dpkg/info/linux-image-2.6.24-etchnhalf.1-686.postinst 2009-07-27 06:37:00.0 +0200 @@ -25,7 +25,7 @@ $|=1; # Predefined values: -my $version = 2.6.18-6-686; +my $version = 2.6.24-etchnhalf.1-686; my $link_in_boot = ; # Should be empty, mostly my $no_symlink= ; # Should be empty, mostly my $reverse_symlink = ; # Should be empty, mostly @@ -34,8 +34,8 @@ my $do_bootfloppy = Yes; # target machine defined my $do_bootloader = Yes; # target machine defined my $move_image= ''; # target machine defined -my $kimage= bzImage; # Should be empty, mostly -my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo +my $kimage= ; # Should be empty, mostly +my $loader= ; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo my $image_dir = /boot;# where the image is located my $clobber_modules = ''; # target machine defined my $relative_links= ; # target machine defined thanks for your fine analysis, could you for completness please post the output of the following: cat /etc/kernel-img.conf -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: severity of 539396 is important
Processing commands for cont...@bugs.debian.org: severity 539396 important Bug #539396 [linux-image-2.6.26-1-amd64] linux-image-2.6.26-1-amd64: memory leak in KVM-72 when having multiple guests running Severity set to 'important' from 'critical' End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535331: Can anyone please explain why 'lilo' was removed from linux-image-*.postinst?
maximilian attems m...@stro.at writes: thanks for your fine analysis, could you for completness please post the output of the following: cat /etc/kernel-img.conf Of course, but do note that there is nothing you can set there which will make the postinst script continue past the line last unless $loaderloc; as $loaderloc will be undefined if $loader is '', and none of these variables are controlled by /etc/kernel-img.conf. bm...@adler:~$ cat /etc/kernel-img.conf # Kernel Image management overrides # See kernel-img.conf(5) for details do_symlinks = Yes do_initrd = Yes do_bootloader = yes Bjørn -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539406: linux-image-2.6.30-1-alpha-smp: fails to load fw for 1st scsi adapter
Package: linux-image-2.6.30-1-alpha-smp Version: 2.6.30-2 Severity: important Well, the firmware loading logic has been flaky on my system for a few releases now. I previously reported bug 527265 against 2.6.29, where the qla1040 firmware would not load at all, and that was resolved in a later 2.6.29 image. In this release (2.6.30-2) I get new/different bad behavior. My system has three QLA1040 cards in it. In the attached console output from the boot, notice that at time 23.256824, the first adapter (scsi0) is located, generates a stack trace trying to load firmware, and fails to initialize the card. (There goes my tape drive!) A little later, at 83.499957, the second adapter is found and this time the firmware loads fine. Ditto for the third adapter after that. -- Package-specific info: -- System Information: Debian Release: 5.0.2 Architecture: alpha Kernel: Linux 2.6.29-2-alpha-smp (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.30-1-alpha-smp depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.30-1-alpha-smp recommends no packages. Versions of packages linux-image-2.6.30-1-alpha-smp suggests: ii aboot 1.0~pre20040408-3 Linux bootloader for the SRM conso ii fdutils5.5-20060227-3Linux floppy utilities pn linux-doc-2.6.30 none(no description available) -- debconf information: linux-image-2.6.30-1-alpha-smp/postinst/depmod-error-initrd-2.6.30-1-alpha-smp: false linux-image-2.6.30-1-alpha-smp/postinst/create-kimage-link-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/preinst/lilo-initrd-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/preinst/abort-install-2.6.30-1-alpha-smp: linux-image-2.6.30-1-alpha-smp/postinst/depmod-error-2.6.30-1-alpha-smp: false linux-image-2.6.30-1-alpha-smp/prerm/removing-running-kernel-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/prerm/would-invalidate-boot-loader-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/postinst/bootloader-test-error-2.6.30-1-alpha-smp: linux-image-2.6.30-1-alpha-smp/preinst/initrd-2.6.30-1-alpha-smp: linux-image-2.6.30-1-alpha-smp/postinst/kimage-is-a-directory: shared/kernel-image/really-run-bootloader: true linux-image-2.6.30-1-alpha-smp/preinst/lilo-has-ramdisk: linux-image-2.6.30-1-alpha-smp/preinst/elilo-initrd-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/preinst/overwriting-modules-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/postinst/bootloader-error-2.6.30-1-alpha-smp: linux-image-2.6.30-1-alpha-smp/preinst/abort-overwrite-2.6.30-1-alpha-smp: linux-image-2.6.30-1-alpha-smp/preinst/bootloader-initrd-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/postinst/old-initrd-link-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/postinst/old-dir-initrd-link-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/postinst/old-system-map-link-2.6.30-1-alpha-smp: true linux-image-2.6.30-1-alpha-smp/preinst/failed-to-move-modules-2.6.30-1-alpha-smp: P00boot -fl 1 Initializing... SROM V3.0 on cpu0 SROM V3.0 on cpu2 SROM V3.0 on cpu1 XSROM V6.0 on cpu1 XSROM V6.0 on cpu2 XSROM V6.0 on cpu0 BCache testing complete on cpu1 BCache testing complete on cpu2 BCache testing complete on cpu0 mem_pair0 - 2048 MB mem_pair1 - 1024 MB mem_pair2 - 1024 MB 20..20..20..21..21..21..23.. please wait 80 seconds for T24 to complete 24..24..24.. Memory testing complete on cpu0 Memory testing complete on cpu1 Memory testing complete on cpu2 starting console on CPU 0 sizing memory 0 2048 MB EDO 1 1024 MB EDO 2 1024 MB EDO starting console on CPU 1 starting console on CPU 2 probing IOD1 hose 1 bus 0 slot 1 - NCR 53C810 bus 0 slot 2 - PCI-PCI Bridge probing PCI-PCI Bridge, bus 2 bus 2 slot 0 - QLogic ISP10X0 bus 0 slot 3 - DE500-BA probing IOD0 hose 0 bus 0 slot 1 - PCEB probing EISA Bridge, bus 1 bus 0 slot 3 - DECchip 21140-AA bus 0 slot 4 - PCI-PCI Bridge probing PCI-PCI Bridge, bus 2 bus 2 slot 0 - QLogic ISP10X0 bus 0 slot 5 - PCI-PCI Bridge probing PCI-PCI Bridge, bus 3 bus 3 slot 0 - QLogic ISP10X0 configuring I/O adapters... ncr0, hose 1, bus 0, slot 1 isp0, hose 1, bus 2, slot 0 tulip0, hose 1, bus 0, slot 3 floppy0, hose 0, bus 1, slot 0 tulip1, hose 0, bus 0, slot 3 isp1, hose 0, bus 2, slot 0 isp2, hose 0, bus 3, slot 0 System temperature is 22 degrees C AlphaServer 4100 Console V6.0-4, 10-MAY-2001 10:11:42 CPU 0 booting (boot dkb0.0.0.2000.1 -flags 1) block 0 of dkb0.0.0.2000.1 is a valid boot block reading 158 blocks from
Processed: Re: live-initramfs: kernel 2.6.30 crash
Processing commands for cont...@bugs.debian.org: reassign 539399 linux-2.6 Bug #539399 [live-initramfs] live-initramfs: kernel 2.6.30 crash Bug reassigned from package 'live-initramfs' to 'linux-2.6'. Bug #539399 [linux-2.6] live-initramfs: kernel 2.6.30 crash Bug No longer marked as found in versions live-initramfs/1.157.2-1. Bug #539399 [linux-2.6] live-initramfs: kernel 2.6.30 crash Ignoring request to alter fixed versions of bug #539399 to the same values previously set retitle 539399 cifs crash with 2.6.30 Bug #539399 [linux-2.6] live-initramfs: kernel 2.6.30 crash Changed Bug title to 'cifs crash with 2.6.30' from 'live-initramfs: kernel 2.6.30 crash' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539399: live-initramfs: kernel 2.6.30 crash
On Fri, Jul 31, 2009 at 05:50:13PM +0400, Vladimir Stavrinov wrote: picture for 686 and real hardware as well. initrd generated in chrooted environment serving as network root filesystem for diskless workstations. This problem concern with network boot only, while using the same initrd to boot from other media cause no problem. It is strange. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539399: live-initramfs: kernel 2.6.30 crash
On Fri, Jul 31, 2009 at 06:55:30PM +0200, Daniel Baumann wrote: cifs is crashing, this is not live specifc, reassigning to kernel. Thanks. -- * Vladimir Stavrinov ** *** v...@inist.ru * * -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
On Friday 31 July 2009, Carlos O'Donell wrote: I'm glad this is fixed in 2.6.31-rc4, do you need any more help from the porters? Well, it might be nice if the responsible change(s) could be identified. Possibly they could be applied/backported to .30. Not sure if it's worth the effort. It might be if e.g. .30 is targeted for a Lenny-and-a-half release. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
On Fri, Jul 31, 2009 at 11:13 AM, Frans Popelen...@planet.nl wrote: On Friday 31 July 2009, Frans Pop wrote: Hmm. The Badness at smp.c warning isn't new of course. That was also there with .24 and .26 (the last working kernel I have). What is new is that the boot now hangs immediately after that point. Whatever the problem is, it looks to be solved in upstream 2.6.31-rc4. That boots correctly (with config based on config-2.6.30-1-parisc64-smp). Attached the dmesg from the successful boot. Important differences: - the Badness at smp.c warning is gone! - the memory zone info is back - init for PCI devices shows up (was absent in .2[46]-smp and .30-smp, but present in 2.6.30-up) I'm glad this is fixed in 2.6.31-rc4, do you need any more help from the porters? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539399: live-initramfs: kernel 2.6.30 crash
Vladimir Stavrinov wrote: This problem concern with network boot only, while using the same initrd to boot from other media cause no problem. It is strange. well, on non-network boot, the cifs module is not loaded, so no surprise about that :) -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539399: live-initramfs: kernel 2.6.30 crash
On Fri, Jul 31, 2009 at 08:18:21PM +0200, Daniel Baumann wrote: well, on non-network boot, the cifs module is not loaded, so no surprise about that :) Yes, I see. I have sent this mail before received Your reassigning message about cifs. -- 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 overflow
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 CC'ing parisc-linux since this is a kernel issue. Helge, Did you ever work around the GOT limitations? To give you a bit of background, position independent code (a module) can't have any virtual addresses (they aren't known), therefore when you need to compute the address of an object you do so using the global offset table. After relocation processing the GOT allows you to translate an object by name to a virtual address e.g. If you take the address of a function, then relocations would cause a GOT entry to be filled such that this entry contains the virtual address of the function. The GOT stubs are pieces of code that load virtual addresses from the GOT and call them. We use GOT stubs to call functions which are not local to the module. 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. However, on 64-bit the long format of ldd has a 16-bit signed immediate offset (0x), meaning it can reach +0x7fff e.g. 4095 GOT slots. Do you have the time to test something out? * Make this conditional on 32-bit vs. 64-bit and allow for 4095 GOT entries on 64-bit. * Fix ELF_GOT_STUB for the 64-bit case. It needs to reassemble a 16-bit offset, the current code is IMO incorrect. i.e. it should be 0x7fff, and use a new reassemble_16 see the PA 2.0 book definition of ldd. * Build kernel. * Test loading NFS moudle. That should be it :-) I tried unloading other modules, but that made no difference (used value remained unchanged). Unloading modules won't help, it's one GOT per module. Does this mean that using nfs on hppa is not possible at all? No, I use nfs on my hppa system. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
On Fri, Jul 31, 2009 at 1:45 PM, Frans Popelen...@planet.nl wrote: On Friday 31 July 2009, Carlos O'Donell wrote: I'm glad this is fixed in 2.6.31-rc4, do you need any more help from the porters? Well, it might be nice if the responsible change(s) could be identified. Possibly they could be applied/backported to .30. Not sure if it's worth the effort. It might be if e.g. .30 is targeted for a Lenny-and-a-half release. I think we should only do this work if .30 *is* targetted for a Lenny-and-a-half release. The hppa team is busy fighting other fires. Cheers, Carlos. -- 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
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
On 07/31/2009 09:03 PM, John David Anglin wrote: 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, Can you explain this idea a little more? Helge -- 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 overflow
On 07/31/2009 08:49 PM, Carlos O'Donell wrote: [...] However, on 64-bit the long format of ldd has a 16-bit signed immediate offset (0x), meaning it can reach +0x7fff e.g. 4095 GOT slots. Do you have the time to test something out? * Make this conditional on 32-bit vs. 64-bit and allow for 4095 GOT entries on 64-bit. * Fix ELF_GOT_STUB for the 64-bit case. It needs to reassemble a 16-bit offset, the current code is IMO incorrect. i.e. it should be 0x7fff, and use a new reassemble_16 see the PA 2.0 book definition of ldd. * Build kernel. * Test loading NFS moudle. Carlos, thanks a lot for those explanations (and keep up your work with NPTL :-)). I'll know what you mean, and if it works it's a good idea. I'll try to come up with a patch. A few notes: - the GOT table is only used for 64bit anyway, so no need to differentiate for 32/64bits - Another possibility could be to sort the tables, so to reduce the number of needed entries. Helge -- 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
On Fri, Jul 31, 2009 at 5:13 PM, Carlos O'Donellcar...@systemhalted.org wrote: On Fri, Jul 31, 2009 at 5:09 PM, Helge Dellerdel...@gmx.de wrote: On 07/31/2009 09:03 PM, John David Anglin wrote: 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, Can you explain this idea a little more? I would also like a little more details. However, this is similar to the DT_PLTGOT issue in dynamic libraries. The value chosen for %dp is arbitrary, and if we made it point into the middle of the GOT table, then you would reference the GOT using both positive and negative offsets. For example, this code: fdesc-gp = (Elf_Addr)me-module_core + me-arch.got_offset; Arbitrary chooses the module %dp to point at the start of got_offset, why not make that got_offset + half way. Let me be clearer, the value of (Elf_Addr)me-module_core + me-arch.got_offset is the start of the GOT table for the module. Cheers, Carlos. -- 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
On Fri, Jul 31, 2009 at 5:09 PM, Helge Dellerdel...@gmx.de wrote: On 07/31/2009 09:03 PM, John David Anglin wrote: 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, Can you explain this idea a little more? I would also like a little more details. However, this is similar to the DT_PLTGOT issue in dynamic libraries. The value chosen for %dp is arbitrary, and if we made it point into the middle of the GOT table, then you would reference the GOT using both positive and negative offsets. For example, this code: fdesc-gp = (Elf_Addr)me-module_core + me-arch.got_offset; Arbitrary chooses the module %dp to point at the start of got_offset, why not make that got_offset + half way. Cheers, Carlos. -- 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
On Fri, Jul 31, 2009 at 06:00:48PM -0400, Carlos O'Donell wrote:
On Fri, Jul 31, 2009 at 5:26 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
I don't have more details... The idea is as Carlos outlined. There's
code in the binutils elf32-hppa.c and elf64-hppa.c files to implement
the above for dynamic libraries. That's what made me think of it.
Binutils is not involved in the kernel module loader, instead
arch/parisc/kernel/module.c (get_fdesc) chooses where the gp will
point to.
If you set gp to the middle of the GOT table, *and* implement
long/short ldd access on 64-bit, then you would get a total of 8191
possible slots per module.
Personally I think the lower risk, quicker fix, is to implement a fix
for 64-bit kernels that uses ldd in format 3 for all offsets 15
bytes, and thus allow you to set MAX_GOTS to 4095.
Note: ldd format 3 can't be used to load immediate values between 15
and -16 bytes.
Is it as simple as:
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ef5caf2..0502fab 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -82,13 +82,6 @@
return -ENOEXEC;\
}
-/* Maximum number of GOT entries. We use a long displacement ldd from
- * 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
-
/* three functions to determine where in the module core
* or init pieces the location is */
static inline int in_init(struct module *me, void *loc)
@@ -126,6 +119,14 @@ struct stub_entry {
};
#endif
+/* Maximum number of GOT entries. We use a long displacement ldd from
+ * the bottom of the table, which has 16-bit signed displacement from
+ * %dp. Because we only use the forward direction, we're limited to
+ * 15-bits - 1, and because each GOT entry is 8-bytes wide, we're limited
+ * to 4095 entries.
+ */
+#define MAX_GOTS (((1 15) - 1) / sizeof(struct got_entry))
+
/* Field selection types defined by hppa */
#define rnd(x) (((x)+0x1000)~0x1fff)
/* fsel: full 32 bits */
@@ -151,6 +152,15 @@ static inline int reassemble_14(int as14)
((as14 0x2000) 13));
}
+/* Unusual 16-bit encoding, for wide mode only. */
+static inline int reassemble_16a(int as16)
+{
+ int s, t;
+ 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) |
@@ -460,12 +470,16 @@ static Elf_Addr get_stub(struct module *me, unsigned long
value, long addend,
*/
switch (stub_type) {
case ELF_STUB_GOT:
+ unsigned int d = get_got(me, value, addend) 0x7fff;
+
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);
+ if (d 15)
+ stub-insns[0] |= reassemble_16a(d);
+
break;
case ELF_STUB_MILLI:
stub-insns[0] = 0x2020;/* ldil 0,%r1 */
I don't think we need to worry about the initial 15-bytes displacement,
since they're all within the first got_entry? (The resulting assembly
looks alright from a 64-bit toolchain:
k...@shortfin ~ $ cat foo.S
.text
a:
ldd 32760(%r27),%r27
break 0,0
a:
0: 53 7b ff f0 ldd 7ff8(dp),dp
int main(void) {
unsigned int opcode = 0x537b;
opcode |= re_assemble_16(32760);
printf(0x%x\n, opcode);
return 0;
}
k...@shortfin ~ $ ./foo
0x537bfff0
Looks pretty happy?
--
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
On 08/01/2009 01:38 AM, Kyle McMartin wrote:
On Fri, Jul 31, 2009 at 06:00:48PM -0400, Carlos O'Donell wrote:
On Fri, Jul 31, 2009 at 5:26 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
I don't have more details... The idea is as Carlos outlined. There's
code in the binutils elf32-hppa.c and elf64-hppa.c files to implement
the above for dynamic libraries. That's what made me think of it.
Binutils is not involved in the kernel module loader, instead
arch/parisc/kernel/module.c (get_fdesc) chooses where the gp will
point to.
If you set gp to the middle of the GOT table, *and* implement
long/short ldd access on 64-bit, then you would get a total of 8191
possible slots per module.
Personally I think the lower risk, quicker fix, is to implement a fix
for 64-bit kernels that uses ldd in format 3 for all offsets 15
bytes, and thus allow you to set MAX_GOTS to 4095.
Note: ldd format 3 can't be used to load immediate values between 15
and -16 bytes.
Is it as simple as:
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ef5caf2..0502fab 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -82,13 +82,6 @@
return -ENOEXEC;\
}
-/* Maximum number of GOT entries. We use a long displacement ldd from
- * 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
-
/* three functions to determine where in the module core
* or init pieces the location is */
static inline int in_init(struct module *me, void *loc)
@@ -126,6 +119,14 @@ struct stub_entry {
};
#endif
+/* Maximum number of GOT entries. We use a long displacement ldd from
+ * the bottom of the table, which has 16-bit signed displacement from
+ * %dp. Because we only use the forward direction, we're limited to
+ * 15-bits - 1, and because each GOT entry is 8-bytes wide, we're limited
+ * to 4095 entries.
+ */
+#define MAX_GOTS (((1 15) - 1) / sizeof(struct got_entry))
+
/* Field selection types defined by hppa */
#define rnd(x)(((x)+0x1000)~0x1fff)
/* fsel: full 32 bits */
@@ -151,6 +152,15 @@ static inline int reassemble_14(int as14)
((as14 0x2000) 13));
}
+/* Unusual 16-bit encoding, for wide mode only. */
+static inline int reassemble_16a(int as16)
+{
+ int s, t;
+ 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) |
@@ -460,12 +470,16 @@ static Elf_Addr get_stub(struct module *me, unsigned long
value, long addend,
*/
switch (stub_type) {
case ELF_STUB_GOT:
+ unsigned int d = get_got(me, value, addend) 0x7fff;
+
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);
+ if (d 15)
+ stub-insns[0] |= reassemble_16a(d);
+
break;
case ELF_STUB_MILLI:
stub-insns[0] = 0x2020; /* ldil 0,%r1 */
I don't think we need to worry about the initial 15-bytes displacement,
since they're all within the first got_entry? (The resulting assembly
looks alright from a 64-bit toolchain:
k...@shortfin ~ $ cat foo.S
.text
a:
ldd 32760(%r27),%r27
break 0,0
a:
0: 53 7b ff f0 ldd 7ff8(dp),dp
int main(void) {
unsigned int opcode = 0x537b;
opcode |= re_assemble_16(32760);
printf(0x%x\n, opcode);
return 0;
}
k...@shortfin ~ $ ./foo
0x537bfff0
Looks pretty happy?
Kyle, you beat me.
Attached is my patch
Tested and works.
r...@c3000:~# uname -a
Linux c3000 2.6.31-rc4-64bit #42 SMP Sat Aug 1 01:37:29 CEST 2009 parisc64
GNU/Linux
r...@c3000:~# lsmod
Module Size Used by
ipv6 493320 70
reiserfs 461624 0
nfs 300704 0
lockd 144456 1 nfs
nfs_acl 5592 1 nfs
sunrpc382312 3 nfs,lockd,nfs_acl
msdos 15032 0
fat91248 1 msdos
Helge
parisc: module.c - fix GOT table overflow with large kernel modules on 64 bit kernels
Signed-off-by: Helge Deller del...@gmx.de
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ef5caf2..d280219 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
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
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Fri, Jul 31, 2009 at 7:38 PM, Kyle McMartink...@mcmartin.ca wrote:
Is it as simple as:
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ef5caf2..0502fab 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -82,13 +82,6 @@
return -ENOEXEC; \
}
-/* Maximum number of GOT entries. We use a long displacement ldd from
- * 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
-
/* three functions to determine where in the module core
* or init pieces the location is */
static inline int in_init(struct module *me, void *loc)
@@ -126,6 +119,14 @@ struct stub_entry {
};
#endif
+/* Maximum number of GOT entries. We use a long displacement ldd from
+ * the bottom of the table, which has 16-bit signed displacement from
+ * %dp. Because we only use the forward direction, we're limited to
+ * 15-bits - 1, and because each GOT entry is 8-bytes wide, we're limited
+ * to 4095 entries.
+ */
+#define MAX_GOTS (((1 15) - 1) / sizeof(struct got_entry))
+
OK
/* Field selection types defined by hppa */
#define rnd(x) (((x)+0x1000)~0x1fff)
/* fsel: full 32 bits */
@@ -151,6 +152,15 @@ static inline int reassemble_14(int as14)
((as14 0x2000) 13));
}
+/* Unusual 16-bit encoding, for wide mode only. */
+static inline int reassemble_16a(int as16)
+{
+ int s, t;
+ t = (as16 1) 0x;
+ s = (as16 0x8000);
+ return (t ^ s ^ (s 1)) | (s 15);
+}
+
OK
static inline int reassemble_17(int as17)
{
return (((as17 0x1) 16) |
@@ -460,12 +470,16 @@ static Elf_Addr get_stub(struct module *me, unsigned
long value, long addend,
*/
switch (stub_type) {
case ELF_STUB_GOT:
+ unsigned int d = get_got(me, value, addend) 0x7fff;
+
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);
+ if (d 15)
+ stub-insns[0] |= reassemble_16a(d);
+
You need to rewrite stub-insn[0[, the long format 3 ldd is a
different opcode, see the PA 2.0 manual, it will no longer be
0x537b.
You also still need a = 15 byte case which uses the old short format
5 ldd with a 14-bit immediate.
break;
case ELF_STUB_MILLI:
stub-insns[0] = 0x2020; /* ldil 0,%r1 */
I don't think we need to worry about the initial 15-bytes displacement,
since they're all within the first got_entry? (The resulting assembly
looks alright from a 64-bit toolchain:
No, we still have to worry about the initial 15-bytes. Within the
first 15-bytes you have one GOT entry (%dp + 0) and thus you need to
add the case for the short format 3 ldd.
Thanks for hacking this up!
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
