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
> > is linux-2.4.3-ac
> 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!
> invalid operand: 00
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
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_expect
>
>
> I had the same problem here, adding #define __builtin_expect
> 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_expect in ../lib/rwsem.c
solved the problem.
>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
Jeff Galloway wrote:
>
> 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.
Hi Jeff,
Well that's problem #1. Source from kernel.org for 2.4 tends to not work on
PPC as it has been lagging on important patches and such.
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
+++ linux-2.4.3-a
[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
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/include Wall
Ws
Jeez David. Although it was insensitive of me to seek succor from the Linux
folks while speaking Microsoft, you needn't be so touchy about it. I
promise I won't commit that sin again, however, at least not in these
circles. (If it makes you feel any better, I'm using a Mac and not a
Wintel.)
F
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
"Grover, Andrew" writes:
| I don't think I understand that first sentence. (Let me respond anyways ;-)
Doh! Sorry, what I meant was that (if I'm understanding this right!)
the AML interpreter being embedd
> > > 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
> 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
> 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
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
* Alan Cox ([EMAIL PROTECTED]) uttered:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
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 an
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
On Fri, 6 Apr 2001, Ion Badulescu wrote:
> On Fri, 6 Apr 2001, Andre Hedrick wrote:
>
> > > You really ought to rename this parameter to pcibus. Even though it doesn't
> > > do justice to the VLB bus, the potential for user error is much smaller.
> >
> > Until today you had a vaild point!
> >
On Fri, 6 Apr 2001, Andre Hedrick wrote:
> > You really ought to rename this parameter to pcibus. Even though it doesn't
> > do justice to the VLB bus, the potential for user error is much smaller.
>
> Until today you had a vaild point!
>
> Promise Ultra100TX2 (20268 chipset).
>
> This is a 66
On Fri, 6 Apr 2001, Ion Badulescu wrote:
> On Fri, 06 Apr 2001 21:30:24 -0700, Andre Hedrick <[EMAIL PROTECTED]> wrote:
> >
> > You killed yourself
> >
> > You do not have a host that will do idebus=66
>
> You really ought to rename this parameter to pcibus. Even though it doesn't
> do j
On Fri, 06 Apr 2001 21:30:24 -0700, Andre Hedrick <[EMAIL PROTECTED]> wrote:
>
> You killed yourself
>
> You do not have a host that will do idebus=66
You really ought to rename this parameter to pcibus. Even though it doesn't
do justice to the VLB bus, the potential for user error is much
You killed yourself
You do not have a host that will do idebus=66
You have now dived you clock timing in half.
You should expect to have a driver time out before the device is
completed.
--
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
Sorry for the null message, fingers slipped :(
Alan Cox wrote:
>
> > ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> > is about the most ominous message one can receive from the IDE driver:
> >
> > 1. it's not in English, so it doesn't tell you jack
>
> It tells you the chipset d
--
--alessandro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Linux: kernel 2.2.19/2.4.3p8 glibc-2.2 gcc-2.96-69 binutils-2.11.90.0.1
Oracle: Oracle8i 8.1.7.0.1 Enterprise Edition for Linux
motto: Tell the truth, there's less to remember.
-
To unsubscribe from this list: send the line "unsubsc
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> is about the most ominous message one can receive from the IDE driver:
>
> 1. it's not in English, so it doesn't tell you jack
It tells you the chipset doesnt support an IDE dma timeout handling function
(ie all it can do is reset
On Wed, 4 Apr 2001 20:00:29 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
>> Been running this configuration over more than 2 years now without such
>> major problems.
>> Could this be the cause?
>
> Quite possibly. There are reasons we ignore bug reports from overclockers
Perhaps. But,
ide
On Wed, 4 Apr 2001, Frank Cornelis wrote:
> Hey,
>
> After I did put in /etc/sysconfig/harddisks
> USE_DMA=1
> my system did crash very badly, I guess after my hard disks did wake up
[SNIPPED...]
>
> BTW: my motherboard runs at 112 Mhz, overclocked, was 100 Mhz.
> Been running this con
Frank Cornelis wrote:
>
> Hey,
>
> After I did put in /etc/sysconfig/harddisks
> USE_DMA=1
> my system did crash very badly, I guess after my hard disks did wake up
> again. For I while I though I'd lose some sectors because of this, I had
> to re-install my RedHat 7.0, had a not so prod
> After I did put in /etc/sysconfig/harddisks
> USE_DMA=1
> my system did crash very badly, I guess after my hard disks did wake up
So you forced DMA on
> BTW: my motherboard runs at 112 Mhz, overclocked, was 100 Mhz.
and ran overclocked
> Been running this configuration over more than
Hi Alan,
looking at 2.4.3-ac2 patch i found that 165x0 serial driver was downgraded
from version 5.05 to 5.02 during the 2.4.3 merge. Looks strange for me,
both 2.4.3 and 2.4.2-ac28 had serial driver 5.05 included.
Is it late 1 April joke ? :))
Best regards.
--
Andrey Panin| Emb
In article <9ae3qj$pc9$[EMAIL PROTECTED]>,
I wrote:
>It's still done manually, and now with the 2.4.3 series we
>have to adjust the scripts a bit.
Scripts adjusted, time for some sleep ;-)
Danny
--
Holland Hosting
www.hoho.nl [EMAIL PROTECTED]
-
To unsubscribe from this list: send the li
Miles Lane <[EMAIL PROTECTED]> wrote:
>You still have the URL for www.bzimage.org in this announcement,
>but there are no incremental patches there for either 2.4.3-ac1
>or 2.4.3-ac2.
They're made as i type ;-)
It's still done manually, and now with the 2.4.3 series we
have to adjust the scripts
Alan, please, replace the unmap_buffer() in fs/buffer.c with
static void unmap_buffer(struct buffer_head * bh)
{
if (buffer_mapped(bh)) {
mark_buffer_clean(bh);
lock_buffer(bh);
clear_bit(BH_Uptodate, &bh->b_state);
clear_bi
Hi Alan,
You still have the URL for www.bzimage.org in this announcement,
but there are no incremental patches there for either 2.4.3-ac1
or 2.4.3-ac2.
Miles
Alan Cox wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
> Intermediate diffs are availab
On Mon, Apr 02, 2001 at 10:40:00AM +, Destroy micro$oft wrote:
> The first time I booted 2.4.3, the system came
> up to the login prompt and promptly froze.
> The second time, I tried to start X, and it
> froze again. Never seen this with the older
> kernels.
Version of X?
> I've got my act
On Thu, 8 Mar 2001, David Weinehall wrote:
> On Mon, Mar 05, 2001 at 09:35:30PM -0500, Richard B. Johnson wrote:
> >
> > Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> > in **MASSIVE** file-system destruction. I have (had) all SCSI
> > disks, using the BusLogic controller.
> >
On Mon, Mar 05, 2001 at 09:35:30PM -0500, Richard B. Johnson wrote:
>
> Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> in **MASSIVE** file-system destruction. I have (had) all SCSI
> disks, using the BusLogic controller.
>
> There is something **MAJOR** going on BAD, BAD, BAD,
"Richard B. Johnson" <[EMAIL PROTECTED]> writes:
> Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> in **MASSIVE** file-system destruction. I have (had) all SCSI
> disks, using the BusLogic controller.
>
> There is something **MAJOR** going on BAD, BAD, BAD, even disks
> that wer
In article <[EMAIL PROTECTED]>,
Richard B. Johnson <[EMAIL PROTECTED]> wrote:
>
>I -- S T R O N G L Y -- suggest that nobody use this kernel with
>a BusLogic SCSI controller until this problem is fixed.
Ho humm..
Anybody who has any ideas or input, please holler. There are no actual
BusLogic
"Richard B. Johnson" wrote:
>
> Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
...
> I -- S T R O N G L Y -- suggest that nobody use this kernel with
> a BusLogic SCSI controller until this problem is fixed.
>
> This is being sent from another machine, not on the list (actual
93 matches
Mail list logo
