David,
Actually it happened only once. then I upgrade my kernel to 2.4.5. problem
disappeared. I just hope this maybe a known problem.
Thanks.
Alex
On Wed, 30 May 2001, David Howells wrote:
>
> > I was running something on my Dell dual p3 box (optiplex gx300). my kernel
> >
> I was running something on my Dell dual p3 box (optiplex gx300). my kernel
> is linux-2.4.3-ac14. I got the following message:
How often did this message occur?
> __rwsem_do_wake(): wait_list unexpectedly empty
> [4191] c5966f60 = { 0001 })
> kenel BUG at rwsem.c:99!
&g
Hi,
I was running something on my Dell dual p3 box (optiplex gx300). my kernel
is linux-2.4.3-ac14. I got the following message:
__rwsem_do_wake(): wait_list unexpectedly empty
[4191] c5966f60 = { 0001 })
kenel BUG at rwsem.c:99!
invalid operand:
CPU:1
EIP
I had my computer go down hard the other day, while it was sitting
idle (some time during the night). This was while in X, so no
messages was visible on the screen, and nothing was recorded in the
logs.
When rebooting, Linux oopsed several times while running ext2.fsck,
requiring reboots every
On Wed, 25 Apr 2001, Alan Cox wrote:
> 2.4.3-ac10
> o Fix reboot notifier unregister in aic7xxx (Arjan van de Ven)
> 2.4.3-ac6
> o Merge aic7xxx driver 6.11 (Justin Gibbs)
I tried vanilla 2.4.3 yesterday, on a box which has one DPTA (IDE) drive
and two Seagat
Oops forgot to update the text. This one is of course not just compile fixes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://ww
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
This isnt a proper release as such, it should just deal with most of the
compile failure/symbol failure problems.
2.4.3-ac14
o
On Mon, 23 Apr 2001, Byeong-ryeol Kim wrote:
> On Sun, 22 Apr 2001, Alan Cox wrote:
>
> > > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > > symbol rwsem_up_write_wake
> > > > /lib/modules/2.4.3-a
On Sun, 22 Apr 2001, Alan Cox wrote:
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > sy
On 22 Apr 2001, Jes Sorensen wrote:
> > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
> Alan> The recommended compilers for non x86 are different too - eg you
> Alan> need 2.96 gcc for IA64, you need 2.95 not egcs for mips and so
> Alan> on.
>
> In principle you just need 2.7.2.3 for m68k, b
Alan Cox wrote:
>
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_down_wri
Hello Alan , To whom is this attributed ? Tia , JimL
On Sun, 22 Apr 2001, Alan Cox wrote:
> o Hopefully fix bugtraq reported netfilter ftp
> flaw
++
| James W. Laferriere | System Techniques |
On 04.22 Dieter Nützel wrote:
> > My belief however is that several million people have gcc 2.96-69+, about 50
> > are likely to have random cvs snapshots and none of them are going to build
> > kernels with them anyway, as they wont work __builtin_expect or otherwise.
> >
> > Alan
>
> I will no
Alan Cox wrote:
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_down_write
On 2001.04.22 11:48 Alan Cox wrote:
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > sym
> > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > symbol rwsem_up_write_wake
> > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > symbol rwsem_down_write_failed
>
> Same thing wit
> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.
I suspect you would find that some of the problems with the initialisers
in structures were common to 2.7.2 across all platforms, but I may be
> "Roman" == Roman Zippel <[EMAIL PROTECTED]> writes:
Roman> Hi, Jes Sorensen wrote:
>> In principle you just need 2.7.2.3 for m68k, but someone decided to
>> raise the bar for all architectures by putting a check in a common
>> header file.
Roman> IIRC 2.7.2.3 has problems with labeled ini
Hi,
Jes Sorensen wrote:
> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.
IIRC 2.7.2.3 has problems with labeled initializers for structures,
which makes 2.7.2.3 unusable for all archs under
On 2001.04.22 09:25 John Cavan wrote:
> Alan Cox wrote:
> > 2.4.3-ac12
> > o Further semaphore fixes (David Howells)
>
> Getting unresolved symbols in some modules (notably, for me, microcode.o
> and radeon.o)...
>
> Using /lib/modules/2.4.3-ac12/kernel/drivers/cha
> My belief however is that several million people have gcc 2.96-69+, about 50
> are likely to have random cvs snapshots and none of them are going to build
> kernels with them anyway, as they wont work __builtin_expect or otherwise.
>
> Alan
I will not add fuel to the fire, but isn't 2.4.XX the
In case everyone missed my original patch =P
http://marc.theaimsgroup.com/?l=linux-kernel&m=98791931115515&w=2
Jes Sorensen wrote:
>
> > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
>
> Alan> The recommended compilers for non x86 are different too - eg you
> Alan> need 2.96 gcc for IA64
Alan Cox wrote:
> 2.4.3-ac12
> o Further semaphore fixes (David Howells)
Getting unresolved symbols in some modules (notably, for me, microcode.o
and radeon.o)...
Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
/lib/modules/2.4.3-ac12/kernel/drivers/c
> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
Alan> The recommended compilers for non x86 are different too - eg you
Alan> need 2.96 gcc for IA64, you need 2.95 not egcs for mips and so
Alan> on.
In principle you just need 2.7.2.3 for m68k, but someone decided to
raise the bar for all arc
f5ibh wrote:
> Alan,
>
>
>>> /usr/src/linux-2.4.3-ac12/lib/lib.a(rwsem.o): In function
>>> `rwsem_up_write_wake':rwsem.o(.text+0x3c6): undefined reference to
>>> `__builtin_expect'
>>
>> Add a
>>
>> #define __builtin_expec
> Are you being deliberately obtuse? 2.97+ snapshots do all support
> builtin_expect, which is what we were discussing.
I think we are having different conversations here.
The only valid inputs to the question are
Recommended
---
egcs-1.1.2 (miscom
Alan,
>> /usr/src/linux-2.4.3-ac12/lib/lib.a(rwsem.o): In function
>> `rwsem_up_write_wake':rwsem.o(.text+0x3c6): undefined reference to
>> `__builtin_expect'
>
>Add a
>
>#define __builtin_expect
I had the same problem here, adding #define __builtin_exp
>There are no gcc 2.97 snapshots that compile the kernel correctly because
>they have the broken bitfield packing ABI change.
Oh right. I didn't know about that particular nicety.
>My belief however is that several million people have gcc 2.96-69+, about 50
>are likely to have random cvs snaps
> On 04.21 Alan Cox wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
> gcc-2.96 spits warnings about possibly-used-before-initialized vars in
> mtrr.c, line 2004:
Its right actually... that could only bite what I believe to be never issued
chips but its right.
-
To u
On 04.21 Alan Cox wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
gcc-2.96 spits warnings about possibly-used-before-initialized vars in
mtrr.c, line 2004:
static void __init centaur_mcr_init(void)
{
int lo,hi;
..
if (anything)
set hi,lo
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
You may well need to 'make clean' before building -ac8 as the GDT layout
has changed a little.
2.4.3-ac11
o Merge Linus 2.4
<[EMAIL PROTECTED]> writes:
> Machine has been locking up between 0-3 times a day sporadically. Nothing
> predictable about it. Hadn't locked up for 3 days, and locked 3x today,
> the last 2 times within 20 minutes of each other. Had run stable with
> 2.2.18, and was running fairly stable on 2.4.
Machine has been locking up between 0-3 times a day
sporadically. Nothing predictable about it. Hadn't locked up for 3
days, and locked 3x today, the last 2 times within 20 minutes of each
other. Had run stable with 2.2.18, and was running fairly stable on 2.4.3
up until about last week. (might
nt patches and such. We're hoping to get
kernel.org caught up ASAP.
Visit here to get the up to date and sometime bleeding edge source for PPC.
http://www.fsmlabs.com/linuxppcbk.html
> Here's my problem:
>
> Problem in compiling linux 2.4.3
>
> Compile er
Thanks. I'll try your suggestions and check on the version of my compiler
and binutils.
on 4/20/01 3:57 AM, David Woodhouse at [EMAIL PROTECTED] wrote:
>
>
> [EMAIL PROTECTED] said:
>> However, I don't think that wishing the world would avoid these
>> dominant (and very useful) formats is a
Jeff Galloway writes:
> Compiler error message:
>
> fork.c: In function copy_mm¹:
> fork.c:353: fixed or forbidden register 68 (0) was spilled for class
> CR0_REGS.
> This may be due to a compiler bug or to impossible asm statements or
> clauses.
You need a newer gcc, I suspect you have egcs i
On Thu, 19 Apr 2001, Alan Cox wrote:
> 2.4.3-ac10
> o Merge Linus 2.4.4pre4
> o Reorder frame buffer probes (Geert Uytterhoeven)
These got somewhat mixed. Remove the duplicates:
--- linux-2.4.3-ac10/drivers/video/fbmem.c.orig Fri Apr 20 09:58:50 2001
+++ li
[EMAIL PROTECTED] said:
> However, I don't think that wishing the world would avoid these
> dominant (and very useful) formats is a realistic expectation. It is
> certainly not "common sense" to assume as such.
Of course it's not a realistic expectation. There are times when it's a pain
to h
Jeff Galloway writes:
> I sent this report to the people indicated below, whose names I got from the
> MAINTAINERS file in the 2.4.3 distribution, but the email address for Mr.
> MacKerras is no longer good and Mr. Chastain wrote me back that he is not
> following 2.4 issues.
I have left Linuxca
Sorry, Tom about the word doc faux pas. I've set out my problem in plain
text below. I got my source from ftp.kernel.org.
Here's my problem:
Problem in compiling linux 2.4.3
Compile error message:
After the compiler message:
gcc D__KERNEL__ -I/home/jeff/kernel/linux/inc
ant to help, here's my problem in (virus free)
plain text:
Problem in compiling linux 2.4.3
Compile error message:
After the compiler message:
gcc D__KERNEL__ -I/home/jeff/kernel/linux/include Wall
Wstrict-prototypes O2 fomit-frame-pointer fno-strict-aliasing
D__powerpc__ -fs
On Thu, 19 Apr 2001, Jeff Garzik wrote:
> I should have gotten off my butt and mentioned this... I would prefer a
> patch without the 2.2.x compat stuff. So instead of all that compat
> code, have
> #include "starfire-2.2.h"
> or similar...
>
> And then starfire-2.2.h would only exist on
Ion wrote:
> On Thu, 19 Apr 2001 21:14:32 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > 2.4.3-ac10
> > o Merge Linus 2.4.4pre4
>
> Well, it seems you have backed out my starfire changes when you merged
> Jeff Garzik's changes from 2.4.4pre4. So here's a new version, diff'ed
> agai
On Thu, 19 Apr 2001 21:14:32 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
> 2.4.3-ac10
> o Merge Linus 2.4.4pre4
Well, it seems you have backed out my starfire changes when you merged
Jeff Garzik's changes from 2.4.4pre4. So here's a new version, diff'ed
against 2.4.3-ac10, which inclu
> I sent this report to the people indicated below, whose names I got from the
> MAINTAINERS file in the 2.4.3 distribution, but the email address for Mr.
> MacKerras is no longer good and Mr. Chastain wrote me back that he is not
> following 2.4 issues.
Well Keith is on holiday I believe and Pau
[EMAIL PROTECTED] said:
> I have not yet heard from Mr. Owens.
This does not surprise me, given the content of your email.
> The compiler error message along with the menuconfig-generated
> configuration file are set out in the attached MS Word document.
I have to assume that you're just wind
Jeff Galloway wrote:
>
> I sent this report to the people indicated below, whose names I got from the
> MAINTAINERS file in the 2.4.3 distribution, but the email address for Mr.
> MacKerras is no longer good and Mr. Chastain wrote me back that he is not
> following 2.4 issues.
Hi Jeff,
Hmm...
EMAIL PROTECTED]>, Paul Mackerras <[EMAIL PROTECTED]>
Subject: Linux 2.4.3 Compile Errors - Power Mac
I have been unable to compile the 2.4 kernel on my Power Mac 7600 (with a
dual 604e/180 processor installed, running kernel 2.2.18 in single processor
mode (which I compiled), but otherwise with
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
You may well need to 'make clean' before building -ac8 as the GDT layout
has changed a little.
2.4.3-ac10
o Merge Linus 2.4
Martin Hamilton wrote:
> FWIW, I didn't have any luck with the 2.4.3 swsusp-v8pre3 patch - my
> C1VE suspended to disk, but on re-reading the memory image from swap
> space the machine reset and we were back to the LILO prompt & fsck.
I can confirm Martin's experience, I got the same results.
A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
(cc'd to the acpi list, where people have also been talking about
this recently...)
Ookhoi writes:
| I tried swsusp on my vaio (also a c1ve :-) and it didn't work because it
| (said it) couldn't stop [kre
you, but not necessarily optimal for any particular
Unix variant, right ? e.g. this could perhaps be simplified
somewhat..
[root@porcupine acpi]# pwd
/usr/src/linux-2.4.3-ac9-swsusp-jogutils/drivers/acpi
[root@porcupine acpi]# wc -l `find . -type f` | grep total
59435 total
My gripe is taken
> > > I was wondering whether the swsusp work might form a useful basis
> > > for the eventual ACPI implementation of the to-disk hibernation
> > > stuff:
> >
> > I (and others) have looked at it. It's a pretty cool patch, but it
> > really isn't the right way to do things.
>
> swsusp is most de
> > I was wondering whether the swsusp work might form a useful basis for
> > the eventual ACPI implementation of the to-disk hibernation stuff:
>
> I (and others) have looked at it. It's a pretty cool patch, but it really
> isn't the right way to do things.
swsusp is most definitely the right
> From: Martin Hamilton [mailto:[EMAIL PROTECTED]]
> | ACPI is meant to abstract the OS from all the "magic
> numbers". It's very
> | possible to do things in a platform-specific way, but if
> you want to handle
> | all platforms, you'd end up with something ACPI-like.
>
> This isn't me talking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
"Grover, Andrew" writes:
| (BTW, read the ACPI 2.0 spec - it's a lot better)
I'm getting there... perhaps tomorrow :-))
| ACPI is meant to abstract the OS from all the "magic numbers". It's very
| possib
> > 2.4.3-ac8
> > o ACPI updates(Andrew Grover)
>
> Patch for ac9 generates a file named linux/acpi-20010413.diff. It partially
> applies, some hunks failed and some offset. Is this rest of your work ?
Oops my screwup. I applied it, it wouldnt build. I remov
> intervals after I use my CD burner, but that just might be coincidental. But
> I'd like to point out that I've never seen this on my VIA686a itself. The P3
> machine is UP too, not SMP. I saw this ever since I switched the machine to
> 2.4.2-ac8 and beyond (previously 2.2.18).
At the moment the
On Tue, Apr 17, 2001 at 10:26:26PM -0400, Byron Stanoszek wrote:
> I've seen this on my Dell P3 700 machine several times. Seems to happen at odd
> intervals after I use my CD burner, but that just might be coincidental. But
I have seen this related to the cd burner as well. it's not a via board
On 04.18 Alan Cox wrote:
>
> 2.4.3-ac9
..
> 2.4.3-ac8
> o ACPI updates(Andrew Grover)
Patch for ac9 generates a file named linux/acpi-20010413.diff. It partially
applies, some hunks failed and some offset. Is this rest of your work ?
--
J.A. Magallon
This particular motherboard is an ASUS CUV4X-DLS, the chipset is a
VIA694XDP, the IDE chipset however is a VIA686b.
I've seen this in all the kernels I've tried with the "ac" patches.
Any kernel I've tried that are NOT SMP work fine.
On Tue, Apr 17, 2001 at 10:26:26PM -0400, Byron Stanoszek wr
On Wed, 18 Apr 2001, Jason Thomas wrote:
> Alan,
>
> This does not seem to fix the problem with "clock timer", which
> repeatedly prints the following message:
>
> probable hardware bug: clock timer configuration lost - probably a VIA686a
>motherboard.
> probable hardware bug: restoring chip c
Alan,
This does not seem to fix the problem with "clock timer", which
repeatedly prints the following message:
probable hardware bug: clock timer configuration lost - probably a VIA686a motherboard.
probable hardware bug: restoring chip configuration.
The machine does not get any further than p
On Wed, 18 Apr 2001, Alan Cox wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
There is no ac9 patch on ftp.kernel.org. Did you put it there?
---
Sergey Kubushin Sr. Unix Administrator
CyberBills, Inc.Phone: 702-567-8857
874
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
VIA users should test this kernel carefully. It has what are supposed to be
the right fixes for the VIA hardware bugs. Obviously
> From: Martin Hamilton [mailto:[EMAIL PROTECTED]]
> Pardon me for butting in, but perhaps this is relevant...
>
> I've seen the odd program which manipulates the ACPI tables/registers
> directly rather than through an ASL compiler then an AML interpreter.
> These appear to use the "magic numbers
> > | that is intentional - first things first.
>
> Probably that's why drivers/media/video/Makefile contains references to
> zoran.o, while zoran.c was ditched?
zoran.c moved, because zoran.o is the output name of the module itself
-
To unsubscribe from this list: send the line "unsubscribe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Alan Cox writes:
| Adding a bloated interpreter for an obscure, misdesigned bios hardware
| description language is simply not my idea of progress.
Pardon me for butting in, but perhaps this is relevant..
On Mon, 16 Apr 2001, Alan Cox wrote:
> o Fix the Zoran driver build (me)
> | This is still not up to date with the master copy
> | that is intentional - first things first.
Probably that's why drivers/media/video/Makefile contains references to
zoran.o, while
Em Mon, Apr 16, 2001 at 05:16:58PM +0100, Alan Cox escreveu:
> > gcc -D__KERNEL__ -I/tmp/build-kernel/usr/src/linux-2.4.3ac7/include -Wall
>-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
>-mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include
>/tmp/bui
> I tried it on my dual P3 box with the VIA chipset and I'm definitely
> getting timeouts for the USB devices. Booting with "noapic" resolves the
> problem for me. Output of lspci for the VIA stuff is:
Thats an unrelated problem. The BIOS on the tyan tiger is broken
>
-
To unsubscribe from thi
Hi!
> > I am aware of a couple of cases where code relied on static
> > variables being allocated contiguously, but, in both cases, those
> > variables were either all zeros or all non-zeros, so my proposed
> > change would not break such code.
>
> Continuous placement is not the only proper
> From: Chris Meadors [mailto:[EMAIL PROTECTED]]
> I saw no mention of the ACPI idle problem I see on my Athlons. Is the
> acpi=no-idle work around the perminate fix?
Fixed. I will be submitting a big ACPI patch to Linus & Alan very soon.
Regards -- Andy
-
To unsubscribe from this list: send t
Alan Cox wrote:
> VIA users should test this kernel carefully. It has what are supposed to be
> the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> as tested as the deduced ones.
>
> 2.4.3-ac7
> o Updated VIA quirk handling for the chipset (Andre Hedrick,
>
On Mon, 16 Apr 2001, Alan Cox wrote:
> > gcc -D__KERNEL__ -I/tmp/build-kernel/usr/src/linux-2.4.3ac7/include
> -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
> -pipe -mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS
> -include
> /tmp/build-kernel/usr/src/lin
> gcc -D__KERNEL__ -I/tmp/build-kernel/usr/src/linux-2.4.3ac7/include -Wall
>-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
>-mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include
>/tmp/build-kernel/usr/src/linux-2.4.3ac7/include/linux/modversions.h
=== Cut ===
make[3]: Entering directory `/tmp/build-kernel/usr/src/linux-2.4.3ac7/drivers/net/wan'
ld -m elf_i386 -r -o wanpipe.o sdlamain.o sdla_ft1.o sdla_x25.o sdla_fr.o sdla_chdlc.o
sdla_ppp.o wanpipe_multppp.o
gcc -D__KERNEL__ -I/tmp/build-kernel/usr/src/linux-2.4.3ac7/include -Wall
-Wstric
> On Mon, 16 Apr 2001, Alan Cox wrote:
> > VIA users should test this kernel carefully. It has what are supposed to be
> > the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> > as tested as the deduced ones.
>
> I saw no mention of the ACPI idle problem I see on my Athl
On Mon, 16 Apr 2001, Alan Cox wrote:
> VIA users should test this kernel carefully. It has what are supposed to be
> the right fixes for the VIA hardware bugs. Obviously the right fixes are not
> as tested as the deduced ones.
I saw no mention of the ACPI idle problem I see on my Athlons. Is th
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
VIA users should test this kernel carefully. It has what are supposed to be
the right fixes for the VIA hardware bugs. Obviously
On Fri, 13 Apr 2001, Scott Prader wrote:
> one of the problems i've been having so far with the 2.4.3 series is the
> fact that USB appears to be futzed. It just doesn't want to work right.
> Also, I compile a lot of things as modules and I've been getting lots of
> unresolved symbols and hence
> system: abit bp6 dual celerons 366 oc'd to 504 work fine with 2.4.2-ac4
> and win98 blahblahblah
So dont overclock
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-in
x27;t tuna fish." -unknown
make[1]: Nothing to be done for `modules_install'.
make[1]: Leaving directory `/usr/src/linux-2.4.3-ac5/arch/i386/lib'
cd /lib/modules/2.4.3-ac5; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{
Dear kernel gurus,
I cannot compile since -ac4 or -ac5 with same config, but it is _not_ related
to the problems reported earlier (rwsem and OLD_GCC).
It is a rwsem problem though, but look:
--8x---snip
gcc -D__KERNEL__ -I/glc/build/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointe
On Thu, Apr 12, 2001 at 07:17:26PM -0400, Greg Louis wrote:
> On 20010412 (Thu) at 1726:11 +0100, Alan Cox wrote:
> >
> > 2.4.3-ac5
>
> > o Fix rwsem compile problem (me)
>
> No such luck, I fear, at least not with egcs-2.91.66:
> /usr/src/linux-2.4.3ac5/include/asm/rwse
On 20010412 (Thu) at 1726:11 +0100, Alan Cox wrote:
>
> 2.4.3-ac5
> o Fix rwsem compile problem (me)
No such luck, I fear, at least not with egcs-2.91.66:
/usr/src/linux-2.4.3ac5/include/asm/rwsem.h:26: badly punctuated
parameter list in #define'
/usr/src/linux-2.4.3ac
Followup to: <[EMAIL PROTECTED]>
By author:Ulrich Drepper <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> "Adam J. Richter" <[EMAIL PROTECTED]> writes:
>
> > >Shouldn't a compiler be able to deal with this instead?
> >
> > Yes.
>
> No. gcc must not do this. There are situation
>Thanks, but Andrey Panin did you one better -- he produced a patch which
>fixes up a good number of these. You should follow lkml more closely :)
I missed that patch and have been unable to find it on google/dejanews.
However, my point is to provide an exhaustive list with sizes (and the tool
f
>> I am aware of a couple of cases where code relied on static
>> variables being allocated contiguously, but, in both cases, those
>> variables were either all zeros or all non-zeros, so my proposed
>> change would not break such code.
>Continuous placement is not the only property defined
"Adam J. Richter" wrote:
> For anyone who is interested, I have produced a list of all
> of the .data variables that contain all zeroes and could be moved to
> .bss within the kernel and all of the modules (all of the modules
> that we build at Yggdrasil for x86, which is almost all). The
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> I am aware of a couple of cases where code relied on static
> variables being allocated contiguously, but, in both cases, those
> variables were either all zeros or all non-zeros, so my proposed
> change would not break such code.
Continuous
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> >Shouldn't a compiler be able to deal with this instead?
>
> Yes.
No. gcc must not do this. There are situations where you must place
a zero-initialized variable in .data. It is a programmer problem.
--
---.
[EMAIL PROTECTED] writes:
>Shouldn't a compiler be able to deal with this instead?
Yes. I sent some email to bug-gcc about this a couple of
months ago and even posted some (probably horribly incorrect) code
showing roughly the change I had in mind in the gcc source code
for the simple ca
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
The merges are tricky in places so this one is to make sure I got the merges
right.
2.4.3-ac5
o Merge Linus 2.4.4pre1
o
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote:
> Shouldn't a compiler be able to deal with this instead?
> (Just a thought.)
> /Johan
The compiler does deal with it. That's why you have a choice when
you write code.
The defacto standard has been that initialized data, regardless of
whether it's i
On Thu, Apr 12, 2001 at 04:44:48PM +0200, [EMAIL PROTECTED] wrote:
> Shouldn't a compiler be able to deal with this instead?
> (Just a thought.)
Search the lkml archives for discussion on this topic around Christmas.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
Shouldn't a compiler be able to deal with this instead?
(Just a thought.)
/Johan
- Original Message -
From: Adam J. Richter <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 12, 2001 2:36 PM
Subject: List of all-zero .data variables in linux-2.4.3 availab
For anyone who is interested, I have produced a list of all
of the .data variables that contain all zeroes and could be moved to
.bss within the kernel and all of the modules (all of the modules
that we build at Yggdrasil for x86, which is almost all). These
are global or static variables
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
This time its almost entirely architecture merges to get ARM back on its
feet and S/390 up and running sanely on 2.4
2.4.3-ac4
o
>I've been seeing a lot of complaints about aic7xxx in the 2.4.3 kernel. I
>think that people are missing the crucial point: aic7xxx won't compile if
>you patch up from 2.4.2, but if you download the complete 2.4.3 tarball,
>it compiles fine.
>
>So, I conclude that the patch was created incorrect
1 - 100 of 138 matches
Mail list logo
