by Russell King

[permalink] [raw]

Subject: Re: 2.6.9-mm1: pc_debug multiple definitions

On Fri, Oct 22, 2004 at 03:39:29PM +0200, Adrian Bunk wrote:
>
> The following compile error comes from Linus' tree:
>
>
> <-- snip -->
>
> ...
> LD drivers/built-in.o
> drivers/pcmcia/built-in.o(.bss+0xf20): multiple definition of `pc_debug'
> drivers/net/built-in.o(.data+0x24ae0): first defined here
> make[1]: *** [drivers/built-in.o] Error 1
>
> <-- snip -->
>
>
> The pc_debug in drivers/pcmcia/ds.c was made non-static in Linus' tree,
> but the global definition of a global variable with such a generic name
> in drivers/net/wireless/prism54/islpci_mgt.c seems to be equally wrong.

I've forwarded it to Dominik to sort out with suggested solutions.
Hopefully Dominik will forward a fix soon.

(PS, I dropped David Hinds from the CC list - David doesn't maintain
2.6 PCMCIA.)

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core

2004-10-23 00:13:17

On Fri, 22 Oct 2004, Andrew Morton wrote:

>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/
>
> - Lots of new patches.
>

which causes the following during build:

OBJCOPY arch/i386/boot/compressed/vmlinux.bin
BFD: Warning: Writing section `.bss' to huge (ie negative) file offset
0xc0435000.
objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
make: *** [bzImage] Error 2

I first thought it might be something in my running kernel, so I tried
it under vanilla 2.6.9, 2.6.9-rc4-mm1, and 2.6.9-ac2 with the same
results. This is the first I've ever seen this - what might be causing
this?

RedHat Enterprise Linux 3.3 WS

ghostwheel:~/linux-2.6.9) scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux ghostwheel 2.6.9-rc4-mm1 #3 Tue Oct 19 10:08:46 PDT 2004 i686 i686 i386
GNU/Linux

Gnu C 3.2.3
Gnu make 3.80
binutils 2.14.90.0.4
util-linux 2.11y
mount 2.11y
module-init-tools 0.9.15-pre4
e2fsprogs 1.32
jfsutils 1.1.2
reiserfsprogs line
reiser4progs 1.0.0
pcmcia-cs 3.1.31
quota-tools 3.09.
PPP 2.4.1
isdn4k-utils 3.1pre4
nfs-utils 1.0.6
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 2.0.17
Net-tools 1.60
Kbd 1.08
Sh-utils 4.5.3
Modules Loaded radeon agpgart ipv6 8250 serial_core ipt_REJECT ipt_state
ip_conntrack iptable_filter ip_tables microcode

--
Charles D. (Chuck) Harding <[email protected]> Voice: 925-423-8879
Senior Computer Associate ICCD/SDD/ICRMG Fax: 925-423-8719
Lawrence Livermore National Laboratory Computation Directorate
Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601
-- People own dogs. Cats own people. --

Attachments:

my.config (26.50 kB)

2004-10-23 06:16:54

by Hans Reiser

[permalink] [raw]

Subject: Re: 2.6.9-mm1

Andrew Morton wrote:

>
> - reiser4: not sure, really. The namespace extensions were disabled,
> although all the code for that is still present. Linus's filesystem
> criterion used to be "once lots of people are using it, preferably when
> vendors are shipping it". That's a bit of a chicken and egg thing though.
> Needs more discussion.
>
>
>
No distro using reiserfs V3 as the default is going to keep doing so
once reiser4 meets their stability requirements. Reiserfs is used by a
lot of people, and reiser4 obsoletes it, and the users know that. None
of the distros have expressed any intent of staying on V3, and they'd be
silly to do it. Many of them have expressed a desire to use reiser4.
Next year, indications are that reiser4 usage by distros as their
default will exceed that which is today possessed by V3. The higher
performance of V4 is going to increase our market share.

I would like to encourage its inclusion as an experimental filesystem
BEFORE vendors ship it. I think first putting experimental stuff in the
kernels used by hackers makes sense. I think it creates more of a community.

I'd like to point out that there is a lot of stuff in the kernel that is
a lot less stable than reiser4.

That said, inclusion in -mm found some bugs, and we are still testing
one of the fixes which was a bit deep. I want to finish that testing
(not more than 7 days) and send you all fixes before asking for inclusion.

Also, Hellwig made a valid point about getting rid of some macros that
reduce readability (I also hate code that prevents editors finding
called functions), and zam is working on fixing that.

Lindows is planning on shipping with reiser4 in its next release. I
would very much like to see our inclusion before that.

2004-10-23 07:22:13

by Avuton Olrich

[permalink] [raw]

Subject: Re: 2.6.9-mm1

On Fri, 22 Oct 2004 03:20:39 -0700, Andrew Morton <[email protected]> wrote:

> - reiser4: not sure, really. The namespace extensions were disabled,
> although all the code for that is still present. Linus's filesystem
> criterion used to be "once lots of people are using it, preferably when
> vendors are shipping it". That's a bit of a chicken and egg thing though.
> Needs more discussion.

*Disclamer: My first post to the list, sorry if something's wrong with
it (blame gmail ;P)*

I've been using reiser4 in four of my computers since it was in -mm.
All partitions (excl. /boot), including 2 boxes that have been up
since (well, reboots for -mm updates from time to time) the reiser4
conversion and not a hiccup since. I'm always shocked when people
speak about how my computers are going to blow up, how people who run
reiser4 must be insane, etc... I've heard it all. Truth is, at the end
of the day, me, Joe End User, has had no issues. I'm not here to say
it's perfect (only the programmers know for sure, IANAP), but it's far
from unpredictable.

The fs's have taken their share of beatings too, testing the new ACPI
stuff lately has lead to plenty of lockups and reiser4 deals much
better than filesystems I have played with in the past.

What I'm trying to say here is I've seen more instability in other
places in the kernel lately than I've seen come from reiser4 at all.
What hurts when including it, when people have the choice not to
compile in and have the big EXPERIMENTAL warning?

2004-10-23 09:08:39

by Alexander Nyberg

[permalink] [raw]

Subject: Re: 2.6.9-mm1

> - kexec and crashdump: this all allegedly works, but I want to *see* it
> work first.

- sys_reboot() calls device_shutdown() which naturally makes my disks go
to sleep and immediatly after spin up when the disk initialization code
comes in. Is there some specific reason why this is needed? Appears to
work for me just removing the function call.

- 3c59x driver together with my 3c509C-TX card hits:
"ff:ff:ff:ff:ff:ff<3>*** EEPROM MAC address invalid"
after doing a kexec-reboot. I tried reseting it at bootup but I couldn't
get it kicking. I couldn't find any specs nor maintainer for this one...

I'll play a bit more with this.
Anywhere I can fetch experimental amd64 patches if there are any?

Alexander

2004-10-23 10:57:14

Attachments:

(No filename) (1.54 kB)
CONFIG (33.91 kB)
Download all attachments

2004-10-31 06:09:35

by Sam Ravnborg

[permalink] [raw]

Subject: Re: 2.6.9-mm1 A little build system bug I guess

On Sun, Oct 31, 2004 at 05:17:00AM +0100, Pedro Larroy wrote:
> Gug
>
> This is a little compile breakage when using -mm to build a kernel with
> make O=directory
>
> In vanilla 2.6.8 I don't have the problem so I presume I'm not the cause
> for it.
>
> I attach my config.
>
> Here comes the output:
>
> compiling...
>
> CC init/initramfs.o
> LD init/built-in.o
> HOSTCC usr/gen_init_cpio
> GEN_INITRAMFS_LIST usr/initramfs_list
> Using shipped usr/initramfs_list
> CPIO usr/initramfs_data.cpio
> ERROR: unable to open 'usr/initramfs_list': No such file or directory

Fixed in latest -mm

Sam