Your email was entirely unrelated to the previous thread, so I split it off.


If you can reproduce this with such a wide variety versions, send your

--

[ message continues ]

Well actually that’s the --build option that was set when building gcc
itself. I have several different gcc versions for both EV5 and EV67. I was
thinking rolling my own Fedora releases, one for myself and possibly

snip

--

[ message continues ]

Found a patch for the 'section mismatch'... the GPREL16 error still remains
though.

[root@jericho linux]# cat ../kernels/linux-2.6.x-PCI_REGISER_SET_VGA.patch
---
a/drivers/pci/pci.c~pci-kill-off-pci_register_set_vga_state-symbol-export
+++ a/drivers/pci/pci.c
@@ -3023,7 +3023,6 @@  EXPORT_SYMBOL(pcim_pin_device);
 EXPORT_SYMBOL(pci_disable_device);
 EXPORT_SYMBOL(pci_find_capability);
 EXPORT_SYMBOL(pci_bus_find_capability);
-EXPORT_SYMBOL(pci_register_set_vga_state);
 EXPORT_SYMBOL(pci_release_regions);
 EXPORT_SYMBOL(pci_request_regions);
 EXPORT_SYMBOL(pci_request_regions_exclusive);

--

[ message continues ]

Attach your .config so others can test.
--

[ message continues ]

It seems the problem, GPREL16, is pretty wide spread. I've tried building
the drivers as modules, since that doesn't appear to be a problem *knock on
wood* but one driver after another, after another, after another generates a
new GPREL16 error! Raid0 drivers, numerous NetFilter modules, IR drivers
(guess I can't use a Hauppauge card), and various other components. I'm
going to try a few more configurations... then hit the sack. I'm pretty sure
this is going to be a long process.

--

[ message continues ]

As has been suggested your best bet for help is to post your .config. 
If you don't want that publicly available then feel free to email it 
privately to Matt and myself.

FWIW, I have two Hauppauge cards (PVR350 card and a Nova-T-500 DVB-T 
card) in my Alpha, and have had no problems compiling the kernel, the 
ivtv modules, the DVB modules, and the IR modules.

If we cannot track down what you are doing differently than the rest of 
us, then there is little chance we can help you.

Cheers
Michael.
--

[ message continues ]

Do you think part of the reason is because of my GLIBC-2.4.11 header
version? I was trying to update it but ran in to numerous header error msgs
and decided to try an slightly older build, such as 2.7, and then upgrading
to 2.11. I spent the better part of my time fixing header issues. Then I
remembered that you can install the headers from glibc and build glibc
against it, but 'make install-headers' hasn't worked in sometime and
apparently don't work in 2.11.x (I tried it).

Now this config setup rather nicely, not GPREL16 errors, but the
'generic-ide' driver wigs out on boot. Going to rebuild minus the
'generic-ide' driver and just stick with the Ali chipset for now. The reason
I included the generic driver, habit from way back in the day when you
weren't sure if the standard driver was going to behave as it's supposed to
;-)

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.34-rc1
# Tue Mar 16 02:07:29 2010
#
CONFIG_ALPHA=y
CONFIG_64BIT=y
CONFIG_MMU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME=y
CONFIG_ARCH_USES_GETTIMEOFFSET=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_GENERIC_IOMAP is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y

#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
CONFIG_AUDIT=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TREE_PREEMPT_RCU is not set
# CONFIG_TINY_RCU is not set
CONFIG_RCU_TRACE=y
CONFIG_RCU_FANOUT=64
# CONFIG_RCU_FANOUT_EXACT is not ...
[ message continues ]

Removed the offending IDE controller, now getting the error below. Looks
like I need to create a NEW initrd image. I'll have to admit, I've done it
before but it this  is the first time I've ever gotten and 'error' for 'not'
doing it. I do have everything rolled into the kernel to boot without a
initrd but in the past I've never had that to work, so I'll stick with it
for now. *thank God for ccache*

TCP cubic registered
rtc-test rtc-test.0: setting system clock to 2010-03-16 16:51:13 UTC
(1268758273)
Freeing unused kernel memory: 208k freed
Red Hat nash version 5.0.32 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
scsi_mod: version magic '2.6.17-1.2187_FC5.6axp mod_unload gcc-4.1' should
be '2.6.34-rc1 mod_unload '
Loading scsi_modsd_mod: version magic '2.6.17-1.2187_FC5.6axp mod_unload
gcc-4.1' should be '2.6.34-rc1 mod_unload '
.ko module
insmscsi_transport_spi: version magic '2.6.17-1.2187_FC5.6axp mod_unload
gcc-4.1' should be '2.6.34-rc1 mod_unload '
od: error insertaic7xxx: version magic '2.6.17-1.2187_FC5.6axp mod_unload
gcc-4.1' should be '2.6.34-rc1 mod_unload '
ing '/lib/scsi_mjbd: version magic '2.6.17-1.2187_FC5.6axp mod_unload
gcc-4.1' should be '2.6.34-rc1 mod_unload '
od.ko': -1 Invalext3: version magic '2.6.17-1.2187_FC5.6axp mod_unload
gcc-4.1' should be '2.6.34-rc1 mod_unload '
id module formatdm_mod: version magic '2.6.17-1.2187_FC5.6axp mod_unload
gcc-4.1' should be '2.6.34-rc1 mod_unload '

Loading sd_moddm_mirror: version magic '2.6.17-1.2187_FC5.6axp mod_unload
gcc-4.1' should be '2.6.34-rc1 mod_unload '
.ko module
insmdm_zero: version magic '2.6.17-1.2187_FC5.6axp mod_unload gcc-4.1'
should be '2.6.34-rc1 mod_unload '
od: error insertdm_snapshot: version magic '2.6.17-1.2187_FC5.6axp
mod_unload gcc-4.1' should be '2.6.34-rc1 mod_unload '
ing '/lib/sd_mod.ko': -1 Invalid module format
Loading scsi_transport_spi.ko module
insmod: error ...
[ message continues ]

New init ram disk, back to the OLD Adaptec SCSI error:

usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using alpha/ev67 performance monitoring.
TCP cubic registered
rtc-test rtc-test.0: setting system clock to 2010-03-16 17:26:39 UTC
(1268760399)
Freeing unused kernel memory: 208k freed
Red Hat nash version 5.0.32 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading aic7xxx.Unable to handle kernel paging request at virtual address
036b036903670360
ko module
insmod(375): Oops -1
pc = [<036b036903670360>]  ra = [<fffffffc0089c9d8>]  ps = 0000    Not
tainted
v0 = 0000000000000001  t0 = 0000000000000001  t1 = 00000000000003ff
t2 = 0000000000000000  t3 = 0000000000000000  t4 = fffffc007d9c7a20
t5 = fffffffc008acc70  t6 = 000000000000000f  t7 = fffffc007d9c4000
s0 = fffffffc008acc90  s1 = 000000000000036b  s2 = 000000000000036b
s3 = fffffc007d9c79f8  s4 = fffffc007d9c7a28  s5 = fffffc007da1bc00
s6 = fffffffc008ad930
a0 = fffffc007da1bc00  a1 = fffffc007d9c7a28  a2 = 000000000000036b
a3 = fffffc007d9c79f8  a4 = fffffc007d9c7b48  a5 = fffffffc0089b434
t8 = fffffc00009001d0  t9 = 0000000000000002  t10= 0000000000000000
t11= 0000000000000001  pv = 036b036903670361  at = 00000000ffffffff
gp = fffffffc008ad7e0  sp = fffffc007d9c78c8
Disabling lock debugging due to kernel taint
Trace:
[<fffffc0000539cec>]
[<fffffc0000520504>]
[<fffffc000059f264>]
[<fffffc0000539fac>]
[<fffffc000053a0d4>]
[<fffffc00005a3a48>]
[<fffffc00005a3cd4>]
[<fffffc00005a2070>]
[<fffffc00005a3c4c>]
[<fffffc00005a3d4c>]
[<fffffc00005a2b9c>]
[<fffffc00005a4568>]
[<fffffc00005a452c>]
[<fffffc0000539d94>]
[<fffffc00003100cc>]
[<fffffc0000351454>]
[<fffffc0000310bb4>]

Code:
Loading dm-log.ko module
Loading dm-region-hash.ko module
Loading dm-mirror.ko module
Loading dm-snapshot.ko module
Making ...
[ message continues ]

Thanks!!! I'll give that a shot, this is one of the files that I
experimented on but I was setting the linker flags. Didn't think to simply
remove -msmall-data CFLAG!

--

[ message continues ]

when I hit the relocation overflow a couple of releases before, I locally
applied this patch, which fixes it for me. I assume the kernel is slightly
bigger this way, but I didn't measure it.

ev6, everything built in, gcc 4.4 I think

Thorsten


diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
index 4759fe7..2cc3cc5 100644
--- a/arch/alpha/Makefile
+++ b/arch/alpha/Makefile
@@ -12,7 +12,7 @@ NM := $(NM) -B
 
 LDFLAGS_vmlinux	:= -static -N #-relax
 CHECKFLAGS	+= -D__alpha__ -m64
-cflags-y	:= -pipe -mno-fp-regs -ffixed-8 -msmall-data
+cflags-y	:= -pipe -mno-fp-regs -ffixed-8
 cflags-y	+= $(call cc-option, -fno-jump-tables)
 
 cpuflags-$(CONFIG_ALPHA_EV4)		:= -mcpu=ev4


-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |
--

[ message continues ]

That patch did the trick!!!! Everything built without issue... I'll post
your patch at bugzilla.kernel.org. Now, just have to test the AIC7xxx driver
and see if it works!  Nope it doesn't, same error as before... aic7xxx
unable to handle kernel paging address at 036b***** I'm going to try
swapping some memory around and see what happens if anything.



--

[ message continues ]

Don't post it to bugzilla. It'll just rot there.

The author should mail linux-alpha@ to get it reviewed.

Matt
--

[ message continues ]

The patch is not suitable, IMHO, for the kernel as it stands.  Some of  
us prefer the small-data model as we must boot off a slow medium that  
is supported by SRM.  Using large-data results in a larger code size.

It would be nice if the build system could detect the need for the  
large-data model before compilation but I can't see how to do that  
without actually compiling the kernel.

Therefore I suggest a kernel config item be added to optionally remove  
the -msmall-data compiler option for those who are building kernels  
with data areas greater than 64kB.  I'll drum up a patch later today.

Cheers
Michael.

--

[ message continues ]

Actually I added several modules into the kernel (raid0/1, router protocols,
and subsystem for TV cards)and it was about 100KB smaller. If push came to
shove, you could simply strip the symbols from the kernel (strip -s vmlinux)
and modules and use gzip -9 (done it in the past and it works fine). Another
thing, how could 2MB make that big of a different on boot time? I used to
use an old 50MB AT drive on my UP2000 (OS installed to 2 IDE drives via a
non-bootable Promise card)and it read at 1MB/s. So, at worst, you're talking
about maybe a 1 to 2 second difference?

Just tested it on my currently modules, went from 35MB to 19MB... not too
shabby.

--

[ message continues ]

Have one.

My error is as follows:

net/built-in.o: In function `svc_auth_unregister':
(.text+0xb822c): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `svc_auth_unregister':
(.text+0xb8268): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `svc_auth_register':
(.text+0xb829c): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `svc_auth_register':
(.text+0xb82d4): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `auth_domain_lookup':
(.text+0xb83ac): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `auth_domain_lookup':
(.text+0xb8430): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `auth_domain_lookup':
(.text+0xb8480): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `auth_domain_put':
(.text+0xb84e4): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `auth_domain_put':
(.text+0xb854c): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `svc_authenticate':
(.text+0xb864c): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `svc_authenticate':
(.text+0xb864c): relocation truncated to fit: GPREL16 against `.sbss'
net/built-in.o: In function `svc_authenticate':
(.text+0xb8678): additional relocation overflows omitted from the output

[ message continues ]

Right, I've confirmed that with the supplied config.  What's happening 
is that the small data area (where certain static data are stored) has 
exceeded 64kB which is the limit under the small data model.  As noted 
elsewhere on this thread it can be solved by compiling with the large 
data model, but that incurs extra CPU instructions whenever the data 
area is accessed.

A better solution, in my view, is to concert some drivers to modules.  I 
note that the config has a large number of devices to be built (some of 
which are denoted as having been tested on x86/x86_64/ia64 only).  I 
converted a few drivers, and most of the selected filesystems (do you 
really need them all at boot time?) into modules.  The kernel then 
builds correctly.

But if people insist on being able to build impractical monolithic 
kernels on Alpha I will post my patch to add a kernel option for the 
large data model.

Cheers
Michael.
--

[ message continues ]

Well a monolithic kernel, which mine isn't, actually runs faster than a
modular one despite being larger... that's been proven several times over
the years. In the past I used to roll monolithic kernels simply for
emergency boot situations and because kernel modules were notorious for not
compiling properly with all kinds of undefined symbols... rolling them into
the kernel was a quick fix. Do you honestly believe all those different
modules, written by a slew of different people, will build properly let
alone function properly? Kernel-2.6.34-rc1 is the FIRST one that I've seen
where the netfilter modules all compiled!

Another thing, some components 'have' to be built into the kernel because
they won't automatically load or the kernel config makes it mandatory. The
auto load function of past kernels has been pretty iffy at best and granted
I've yet to actually load this release, I do have my doubts. So important
things such as my aic7xxx drivers, ali drivers, 751 chipset, etc. I roll
into the kernel itself.

The things that you've stated I can understand but on when you get right
down to it, it's not a major issue. My 'monolithic' kernel is only 1.9MB @
89MB/s. Personally I feel they should make small-data an patch addon, it
would save a lot of people a some grief. Some ppl will select them (modules)
either intentionally or by accident and the majority of folks are not
running AT HDD's on a flaky IDE controller. Sincerely Will L G

PS Whatever you guys decide please make it obvious... the aboot/kernel
change a few years ago, caused a lot of Alpha Linux users to bug out...
About the only ppl aware of the change was Ivan and a handful of Debian
folks.


--

[ message continues ]

can you bisect this?

Justin P.Mattock
--

[ message continues ]