> > compiler (e.g. on sparc64). This test will barf on gcc-2.96 up to -67 and
> > Jakub
>
> ehhmm..
>
> didn't barf here with 2.96-70.
Which is correct
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows: A server creates a named pipe
Pipes are not bidirectional in Linux. We follow traditional non stream
behaviour
> /dev/spx". I experiemented with socket-based pipes under
> Please, do not do so. That depends on the PACKAGE name and version, and there
> is no standard way of versioning a patched gcc.
> The -54 is a RH'ism, for example Mandrake Cooker includes patches from
> different sources, and gcc is versioned like
>
> werewolf:~# rpm -q gcc
> gcc-2.96-0.33mdk
> kernel source is broken as designed. /usr/include/{linux,asm} must be
> real directories that are shipped as part of glibc, not symlinks to
> some random version of the kernel. Fix /usr/include.
You need to fix the kernel headers too - libc5 doesnt work otherwise
-
To unsubscribe from this
Hi,
I asked David Hinds to write up an outline of the things that
will be needed to get PCMCIA support cleanly and completely
integrated into the kernel tree.
David has expressed that he'll not be able to participate in
this work. He has his hands full with his day job and his
role as
You know where to get it:
ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.1-3.diff.gz
Fixes:
1) pskb_expand_tail could corrupt SKB frag lists in some
cases, leading to OOPS
2) Need to check for out of window data even in the
partial packet cases of tcp_data_queue
3)
On Fri, 2 Feb 2001, Mike Galbraith wrote:
> > Where exactly do you see the leaks?
>
> (I don't have a solid grip yet.. just starting to seek)
Heh. I figured this must be a nice defenseless little buglet
I could pick on (ramfs is pretty darn simple). Critter might
not be quite as defenseless
I downloaded the pcmcia-cs 3.1.24 package and hand-merged the bugfix(es?)
into 2.4.1's xirc2ps_cs.c. A(n attempt at a) patch to bring 2.4.1
up to pcmcia-cs's version is attached to this email. So far, no
problems, but it'll be at least 48 hours before I can say whether
it happens or not.. This
On Fri, 02 Feb 2001 21:28:13 -0800,
Martin Bogomolni <[EMAIL PROTECTED]> wrote:
>c02817f0 usb_match_id_R__ver_usb_match_id
>The solution was to add the #include header
>into each of the drivers affected.
Wrong. See http://www.tux.org/lkml/#s8-8
-
To unsubscribe from this list: send the line
While trying to compile a new driver for an 802.11 pci card, I started
work on upgrading the linux-wlan utilites to 2.4.0. Other than the
usual small things (like replacing references to kfree_s with kfree) the
work was going pretty smoothly.
I spent a good hour though, trying to debug one
On Fri, Feb 02, 2001 at 11:54:31PM -0500, [EMAIL PROTECTED] wrote:
>
> Each time I get a transmit timeout, or UDP: short packet error,
> networking on my laptop seems to go down. Reinsertion of the
> card temporarily fixes it, and if I leave it long enough it
> also fixes itself.
Does the same
I've now installed 21.6 downloaded from metlab
and all seems to be ok now... well at
least the dell box.. compaq boot sector may
have been blown off for some reason..it won't
boot at all athough this time it's a different
way of being stuck like LI instead of LILO.
I will try ibm box in the
Many thanks to all who have suggested to use UNIX domain sockets. That was
my first thought--I just didn't know how to preserve the existing named
interface. And yes, I have consulted several "decent" UNIX programming
books which have led me to the likelihood that what I want to do cannot be
My logs show the following:
xirc2ps_cs.c 1.31 1998/12/09 19:32:55 (dd9jn+kvh)
eth0: Xircom: port 0x300, irq 3, hwaddr 00:80:C7:1E:28:2A
eth0: MII link partner: 0021
eth0: MII selected
eth0: media 10BaseT, silicon revision 4
UDP: short packet: 137/58
NETDEV WATCHDOG: eth0: transmit timed out
Do not trust the second channel to ATA devices.
Only ATAPI can live there.
I watch it all day long eat my second drives.
The OSB4 is not a pretty thing to play with, and I will have the chance to
fix the CSB5 before it goes final.
Cheers,
On Fri, 2 Feb 2001, Dunlap, Randy wrote:
> I'm also
> "Brian" == Brian Wellington <[EMAIL PROTECTED]> writes:
Brian> No, it clearly says that glibc contains its own versions of
Brian> the net/* and scsi/* files, and that /usr/include/asm and
Brian> /usr/include/linux should remain as they were. Since they
Brian> were symlinks
On 3 Feb 2001, Brian May wrote:
> > "Keith" == Keith Owens <[EMAIL PROTECTED]> writes:
>
> >> {PB} This was necessary for libc5, but is not correct when
> >> using glibc. Including the kernel header files directly in user
> >> programs usually does not work (see question 3.5).
On Fri, 2 Feb 2001, Jakub Jelinek wrote:
> You can do:
> if [ "$CC" = gcc ]; then
> echo 'inline void f(unsigned int n){int
>i,j=-1;for(i=0;i<10&<0;i++)if((1UL< > test.c
> gcc -O2 -o test test.c
> if ./test; then echo "*** Please don't use this compiler to compile kernel"; fi
> rm -f
> "Keith" == Keith Owens <[EMAIL PROTECTED]> writes:
>> {PB} This was necessary for libc5, but is not correct when
>> using glibc. Including the kernel header files directly in user
>> programs usually does not work (see question 3.5). glibc
>> provides its own and header
Jeff writes:
> I understand that both ext3fs and
> reiserfs will try to fix corrupt filesystems (or at least filesystems
> with unprocessed log entries) in-place even if they're mounted
> read-only. Clearly, virtual replay means more work, but -- just for
> fun -- here are some cases in which it
J Sloan writes:
> I discovered that lvm seems to have a problem
> with compaq raid controllers - the partitions
> don't have the normal names like /dev/sda1,
> but instead names like /dev/ida/c0d0p1 -
>
> lvm seems to works OK, but lvmdiskscan freaks...
>
> lvmdiskscan -- filling directory
I'm also getting a ton of these, along with lots of
file corruption. I could handle the timeouts and
rebooting every once in awhile if I didn't also have
the corruption.
Do I have some incorrect IDE parameters?
(using 2.4.0, not 2.4.1)
dual Pentium III 933 MHz (STL2 board)
SAMSUNG 20 GB IDE
On Thu, Jan 04 2001 at 17:49:46 EST, Stephen C. Tweedie wrote:
> I will be adding support for virtual replay for root filesystems to
> act as a last-chance way of recovering if you really cannot write to
> the root, but journaling filesystems really do expect to be able to
> write to the
Ion Badulescu <[EMAIL PROTECTED]> writes:
> On Fri, 2 Feb 2001, Alan Cox wrote:
>
> > Oh I can see why Hans wants to cut down his bug reporting load. I can also
> > say from experience it wont work. If you put #error in then everyone will
> > mail him and complain it doesnt build, if you put
On Sat, 3 Feb 2001 00:49:26 -0200,
Fr d ric L. W. Meunier <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> Relying on /usr/include/{linux,asm} always pointing at the
>> current kernel source is broken as designed.
>
>From glibc 2.2.1 FAQ:
>
>2.17. I have /usr/include/net and /usr/include/scsi
> "Frédéric" == Frédéric L W Meunier <[EMAIL PROTECTED]> writes:
Frédéric> Keith Owens wrote:
>> Rule 2. Any glibc that has a symlink from
>> /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}
>> is wrong.
Frédéric> Such symlinks are created by the user.
Keith Owens wrote:
> Rule 2. Any glibc that has a symlink from
> /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}
> is wrong.
Such symlinks are created by the user.
> Relying on /usr/include/{linux,asm} always pointing at the
> current kernel source is broken as designed.
From
> I've countless web searches and linux-kernel archives, but I haven't yet
> found the answer to my question.
>
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows: A server creates a named pipe
> in the /tmp directory. Any
On Fri, 2 Feb 2001, David Lang wrote:
> Thanks, that info on sendfile makes sense for the fileserver situation.
> for webservers we will have to see (many/most CGI's look at stuff from the
> client so I still have doubts as to how much use cacheing will be)
CGI performance isn't directly
> svgalib: mmap error in paged screen memory.
A fix is to build SVGAlib without background execution support.
Take a look at http://www.arava.co.il/matan/svgalib/hypermail/
--
Frédéric L. W. Meunier - http://www.pervalidus.net/
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ
On Sat, 3 Feb 2001, Hans Reiser wrote:
> Alan Cox wrote:
> >
> > > It makes sense to refuse to build a piece of the kernel if it break's
> > > a machine - anything else is a timebomb waiting to explode.
> >
> > The logical conclusion of that is to replace the entire kernel tree with
> >
> >
Hmm. I just downloaded the lilo 21.6 source and the patch appears to
have
already been applied. I got 21.6 from:
http://ftp.cnr.it/Linux/system/boot/lilo/lilo-21.6.1.tar.gz
Miles Lane wrote:
>
> Chris Mason wrote:
> >
> > On Friday, February 02, 2001 03:36:18 PM -0500 [EMAIL
> image=/boot/bzImage
> label=linux
> append="root=/dev/ide/host0/bus0/target0/lun0/part1 vga=3845"
root=/dev/ide/host will work the same as root=/dev/hda... in pre-devfs
-d
--
There is a natural aristocracy among men. The grounds of this are virtue and
talents. Thomas Jefferson
The
Chris Mason wrote:
>
> On Friday, February 02, 2001 03:36:18 PM -0500 [EMAIL PROTECTED]
> wrote:
>
> > I'm not sure whether this problem is related
> > to 2.4 kernel.
> >
>
> I suspect it is a reiserfs problem, and that you are using lilo older than
> 21.6. Are you mounting /boot with -o
On Thu, Feb 01 2001, Anders S. Buch wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> It seems that the ide/cdrom/amd756 code can cause some bad lockups, at
> least on my system. I have an Athlon 500 system running the 2.4.1 kernel
> with Redhat 6.1 + updated modutils,
On Fri, 2 Feb 2001, Ion Badulescu wrote:
> On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos <[EMAIL PROTECTED]> wrote:
>
> > Sometimes when I reboot the system, as soon as the eepro100 module is
> > loaded, I start to get these msgs on the screen:
> >
> > eth0: card reports no resources.
Hugh Dickins wrote:
>
> I wonder (you or hpa may very quickly point out why this is stupid
> and impossible), could we move the identify_cpu() calls into
> cpu_init()? I used to think it was called too early for that, but
> now I see it's already using current, smp_processor_id(), printk().
>
I thought mkfifo was only unidirectional...
Brendan
Please cc: me personally, as I am not subscribed.
-Original Message-
From: J . A . Magallon [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 4:47 PM
To: Miller, Brendan
Cc: 'linux-kernel @ vger . kernel . org'
Subject: Re:
On 2 Feb 2001, at 20:17, Urban Widmark wrote:
>
> > >I did this and compiled it into the kernel. It detects it at boot
> > >(via- rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the
> > >hardware address (mac address?) is 00-00-00-00-00-00.
>
> This is a good example of what is missed by
Hi Udo!
On Thu, 01 Feb 2001, Udo A. Steinberg wrote:
>
> Hi all,
>
> With all the latest kernels (at least since 2.4.0-test12)
> I have had occasional problems with a PS/2 keyboard when
> switching back and forth between X and text consoles.
>
> In most cases the problem occurs when
On Fri, Feb 02, 2001 at 02:58:14PM -0800, [EMAIL PROTECTED] wrote:
> Now, it seems to me, as long as the ReiserFS folks are going to be getting the
> bulk of the extra work(/mail/whatever) out of this, and they've been advised
> of the risks to their own person and are ok with that (which they
Perhaps man 2 mkfifo ?
On 02.03 "Miller, Brendan" wrote:
>
> I've countless web searches and linux-kernel archives, but I haven't yet
> found the answer to my question.
>
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows:
Ingo Molnar wrote:
>
> On Fri, 2 Feb 2001, Rajagopal Ananthanarayanan wrote:
>
> > Do you really have worker threads? In my reading of the patch it seems
> > that the wtd is serviced by keventd. [...]
>
> i think worker threads (or any 'helper' threads) should be avoided. It can
> be done
I've countless web searches and linux-kernel archives, but I haven't yet
found the answer to my question.
I'm porting some software to Linux that requires use of a bidirectional,
named pipe. The architecture is as follows: A server creates a named pipe
in the /tmp directory. Any client can
On Fri, 2 Feb 2001, H. Peter Anvin wrote:
>
> > diff -up --recursive --new-file linux-2.4.0-ac12.macro/include/asm-i386/bugs.h
>linux-2.4.0-ac12/include/asm-i386/bugs.h
> > --- linux-2.4.0-ac12.macro/include/asm-i386/bugs.h Sun Jan 28 09:41:20 2001
> > +++
On Sat, Feb 03, 2001 at 12:40:03AM +0100, J . A . Magallon wrote:
> Please, do not do so. That depends on the PACKAGE name and version, and there
> is no standard way of versioning a patched gcc.
> The -54 is a RH'ism, for example Mandrake Cooker includes patches from
> different sources, and gcc
Hi,
Unfortunately you are too right. It appears that the "!!!HACK,HACK,HACK!!!
2048 is only assumed" line is gone in 2.4.1, but is back in 2.4.1-ac1. Can
this be fixed?
Regards,
infernix
- Original Message -
From: "Kai Germaschewski" <[EMAIL PROTECTED]>
To: "infernix" <[EMAIL
On 02.02 Ken Moffat wrote:
> Hi guys,
> I guess I'm doing something stupid, so please can somebody point it out
> and put me out of my misery ?
>
> Copied a plain 2.4.0 tree to a new directory, patched it to 2.4.1 without
> any errors. Then I realised it had all the object files from my
I would agree with you, and I was about to write something saying that trusting
that rpm is installed is bad, except that then I realized, only RedHat made this
error, and only RedHat installs need this protection.
Now, if we want to have a more general bad gcc's list, and we envision this code
On 02.02 H. Peter Anvin wrote:
> "J . A . Magallon" wrote:
> >
> > On 02.02 Christoph Rohland wrote:
> > > "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> > >
> > > > What happened with this being a management tool for shared memory
> > > > segments?!
> > >
> > > Unfortunately we lost this
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote:
>
> Following is the current state of my CPU capabilities rework. It
> introduces a new global variable, common_x86_capability, which holds the
> common set of flags for CPUs. The boot_cpu_data is used appropriately
> again, i.e. it's treated as
Michael H. Warfield writes:
> On Fri, Feb 02, 2001 at 03:36:46PM -0800, David S. Miller wrote:
> So block them using the /etc/mail/access database for sendmail
> and do it with a "451" error code. The data will back up on their
> mail server and start clogging their mail spool till
On Fri, Feb 02, 2001 at 03:36:46PM -0800, David S. Miller wrote:
> Ok, it seems somebody is running a cron script or similar
> to keep resubscribing that [EMAIL PROTECTED] address
> to linux-kernel.
So block them using the /etc/mail/access database for sendmail
and do it with a "451"
On 02.02 Hans Reiser wrote:
> Alan Cox wrote:
> > Run a small shell check and let it fail if the shell stuff errors.
> >
> > The fragment you want is
> >
> > if [ -e /bin/rpm ]; then
> > X=`rpm -q gcc`
> > if [ "$X" = "gcc-2.96-54" ]; then
> > echo "*** GCC
Ok, it seems somebody is running a cron script or similar
to keep resubscribing that [EMAIL PROTECTED] address
to linux-kernel.
So if you see the "moderation" message back from a posting
you make to linux-kernel, please dont' report it to us here
at vger.kernel.org, we know about it.
Later,
On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos <[EMAIL PROTECTED]> wrote:
> Sometimes when I reboot the system, as soon as the eepro100 module is
> loaded, I start to get these msgs on the screen:
>
> eth0: card reports no resources.
> eth0: card reports no RX buffers.
> eth0: card
David Lang writes:
> right, assuming that there is enough sendfile() benifit to overcome the
> write() penalty from the stuff that can't be cached or sent from a file.
>
> my question was basicly are there enough places where sendfile would
> actually be used to make it a net gain.
There
On Fri, 2 Feb 2001, Rajagopal Ananthanarayanan wrote:
> Do you really have worker threads? In my reading of the patch it seems
> that the wtd is serviced by keventd. [...]
i think worker threads (or any 'helper' threads) should be avoided. It can
be done without any extra process context, and
Let's see all the work being done for clustering would definitely
benefit... all the static images on your webserver--and static images
makes up most of the bandwidth from web servers (images, activeX controls,
java apps, sound clips...)... NFS servers, Samba servers (both of which
are used
On Sat, 03 Feb 2001 00:04:16 +0100,
Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
>I had some problems while compiling some applications
>with the 2.4.0 kernel.
>The problem was a conflict between string.h from the libc
>and the one from the kernel, which is included in fs.h
Rule 1. Applications
Benjamin LaHaise wrote:
>
> Hey Ingo,
>
> On Fri, 2 Feb 2001, Ingo Molnar wrote:
>
> > - first of all, great patch! I've got a conceptual question: exactly how
> > does the AIO code prevent filesystem-related scheduling in the issuing
> > process' context? I'd like to use (and test) your AIO
On Fri, 2 Feb 2001, Benjamin LaHaise wrote:
> Thanks! Right now the code does the page cache lookup allocations and
> lookups in the caller's thread, [...]
(the killer is not the memory allocation(s), if there is enough RAM then
we can get a free page without having to block.)
The real
right, assuming that there is enough sendfile() benifit to overcome the
write() penalty from the stuff that can't be cached or sent from a file.
my question was basicly are there enough places where sendfile would
actually be used to make it a net gain.
David Lang
On Fri, 2 Feb 2001, David S.
David Lang writes:
> Thanks, that info on sendfile makes sense for the fileserver situation.
> for webservers we will have to see (many/most CGI's look at stuff from the
> client so I still have doubts as to how much use cacheing will be)
Also note that the decreased CPU utilization
I had some problems while compiling some applications
with the 2.4.0 kernel.
The problem was a conflict between string.h from the libc
and the one from the kernel, which is included in fs.h
So, using and at the same time
brings some conflicts.
It seems to me that should not be apparent
from
Hello,
The system is as follows:
- Intel CA810EAL motherboard (built-in EtherExpress Pro 10/100)
- 128MB RAM
- 10GB IDE HD (Western Digital WD100)
- Linux kernel 2.2.18
Sometimes when I reboot the system, as soon as the eepro100 module is
loaded, I start to get these msgs on the screen:
eth0:
Thanks, that info on sendfile makes sense for the fileserver situation.
for webservers we will have to see (many/most CGI's look at stuff from the
client so I still have doubts as to how much use cacheing will be)
David Lang
On Fri, 2 Feb 2001, David S. Miller wrote:
> Date: Fri, 2 Feb 2001
Hello,
The system is as follows:
- Intel CA810EAL motherboard (built-in EtherExpress Pro 10/100)
- 128MB RAM
- 10GB IDE HD (Western Digital WD100)
- Linux kernel 2.2.18
Sometimes when I reboot the system, as soon as the eepro100 module is
loaded, I start to get these msgs on the screen:
eth0:
On Sat, Feb 03, 2001 at 01:03:00AM +0300, Hans Reiser wrote:
> My design objective in ReiserFS is not to say that it wasn't my fault they had
> that bug because they are so ignorant about a filesystem that
> really isn't very important to them unless it screws up. My design objective is
> to
On Sat, 3 Feb 2001, Hans Reiser wrote:
> That said, my opinion is that bug reporting load is not as important as bug
> avoidance, but I understand your position has merit to it also.
If you do it, at least restrict it to 2.96.0. Maybe Red Hat will see the
light and release a fixed 2.96.1...
On Fri, 2 Feb 2001 16:39:18 -0500 (EST),
Alan Cox <[EMAIL PROTECTED]> wrote:
>Large numbers of people routinely build the kernel with 'unsupported' compilers
gcc version 2.96-ia64-000717 snap 001117 - works for me doing cross
compile from ia32 to ia64. Anybody adding #ifdef, please include
Alan Cox wrote:
>
> > > their kernel, something putting #ifdefs all over it will mean they have to
> > > mess around to fix too.
> > >
> > A moment of precision here. We won't test to see if the right compiler is used,
> > we will just test for the wrong one.
>
> Ok that makes a lot more sense
On Fri, 2 Feb 2001, Pavel Machek wrote:
> Hi!
>
> > I am asking because I have just ordered a new drive for my Vaio (8.1 gig
> > in a 8.45mm drive!) and I want to install 2.4.x on it. (I like getting
>
> 8.1GB in under centimeter? That's 8.1GB in compactflash slot?
Standard laptop drive size
David Lang writes:
> 1a. for webservers that server static content (and can therefor use
> sendfile) I don't see this as significant becouse as your tests have been
> showing, even a modest machine can saturate your network (unless you are
> useing gigE at which time it takes a skightly
Alan Cox wrote:
>
> > It makes sense to refuse to build a piece of the kernel if it break's
> > a machine - anything else is a timebomb waiting to explode.
>
> The logical conclusion of that is to replace the entire kernel tree with
>
> #error "compiler or program might have a bug. Aborting"
On Fri, 2 Feb 2001, Alan Cox wrote:
> Oh I can see why Hans wants to cut down his bug reporting load. I can also
> say from experience it wont work. If you put #error in then everyone will
> mail him and complain it doesnt build, if you put #warning in nobody will
> read it and if you dont put
Richard B. Johnson writes:
> WARNING!! Messages to linux-kernel are now being intercepted
> (and answered) by this company:
> On Fri, 2 Feb 2001 [EMAIL PROTECTED] wrote:
>
> My message was sent directly to linux-kernel, with no cc address.
> It should not have gone anywhere else.
I've
> my convenience matters as much as that of the users. I don't want to use
> #ifdefs, I want it to die explosively and verbosely informatively. make isn't
> the most natural language for that, but I am sure Yura can find a way.
Run a small shell check and let it fail if the shell stuff errors.
Gérard Roudier wrote:
>
> So, why not using a pure software flag in memory and only tampering the
> things if the offending interrupt is actually delivered ? If the given
> interrupt is delivered and the software mask is set we could simply do:
>
> - MASK the given interrupt
> - EOI it.
> -
Hi,
I was trying 2.4.1 kernel but under some IO load (bonnie++)
DMA gets disabled with following messages:
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: timeout waiting for DMA
I have a box with:
a couple of analog ISA modem cards in it which have 8 modems a piece
the modems use devices ttyS4-19
a realtek 8039 pci ethernet card (100 mbit)
486 dx
Its running redhat 6.2 and a 2.2.17 kernel with ppp ip-forwarding
ip aliasing and ip masq support.
The kernel is
> > their kernel, something putting #ifdefs all over it will mean they have to
> > mess around to fix too.
> >
> A moment of precision here. We won't test to see if the right compiler is used,
> we will just test for the wrong one.
Ok that makes a lot more sense
-
To unsubscribe from this
- Original Message -
From: "Peter 'Luna' Runestig" <[EMAIL PROTECTED]>
To: "Linux Kernel Mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, January 24, 2001 7:29 PM
Subject: PROBLEM: 2.2.19pre7 opps on low mem machine
> [1.] One line summary of the problem:
> Oops with 2.2.19pre7 on
On Fri, 2 Feb 2001, David S. Miller wrote:
>
> Richard B. Johnson writes:
> > WARNING!! Messages to linux-kernel are now being intercepted
> > (and answered) by this company:
> > On Fri, 2 Feb 2001 [EMAIL PROTECTED] wrote:
> >
> > My message was sent directly to linux-kernel, with no cc
Alan Cox wrote:
>
> > As it stands, there is no way to determine programatically whether
> > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > version -- which, needless to say, is a bit difficult to do from the
> > C code about to be compiled. So I can't really blame Hans
Alan Cox wrote:
>
> > my convenience matters as much as that of the users. I don't want to use
> > #ifdefs, I want it to die explosively and verbosely informatively. make isn't
> > the most natural language for that, but I am sure Yura can find a way.
>
> Run a small shell check and let it
> OK, following the reiserfs/compiler thread, I can see now that my bug report
> may have been ignored since I was using a non-kosher compiler (although I
> have used it since late October -99 without any problems). Or, it might not
> have been ignored, just nobody told me he/she wasted some time
On Fri, Feb 02, 2001 at 09:57:39PM +, Alan Cox wrote:
: > As it stands, there is no way to determine programatically whether
: > gcc-2.96 is broken or now. The only way to do it is to check the RPM
: > version -- which, needless to say, is a bit difficult to do from the
: > C code about to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wednesday, Richard B. Johnson ([EMAIL PROTECTED]) wrote:
> Now just a cotton-picken minute. When was the last time you
> accessed that site? I spent most of last night looking through
> EMPTY directories with files that are invisible to ftp
I have a quick question regarding the ethertap device and routing. We're seeing
the contents of the packet coming up through the ethertap device just fine, but
the originating address seems to be overwritten with the ethertap device's
address.
Am I missing something obvious here? I'm positive
Alan Cox wrote:
>
> > Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use
> > reiserfs. It is that simple. How can you even consider defending allowing the
> > use of it without requiring a positive affirmation by the user that they don't
> > know what they are doing and
> As it stands, there is no way to determine programatically whether
> gcc-2.96 is broken or now. The only way to do it is to check the RPM
> version -- which, needless to say, is a bit difficult to do from the
> C code about to be compiled. So I can't really blame Hans if he decides
> to outlaw
Dick, and Mark, thanks. It's compiling nicely now. We learn by experience.
Cheers, Ken
> Not to worry. In your new Linux directory tree do:
>
> cd include
> mv asm /tmp # or /usr/src, someplace temporary.
>
> cd .. # Back to Linux
> cp .config .. # Save your configuration
> make
> Copied a plain 2.4.0 tree to a new directory, patched it to 2.4.1 without
> any errors. Then I realised it had all the object files from my last
> compile, so I thought "make mrproper" was called for. It did a little,
> then
You copied the link and turned it into its contents
> rm:
Lets not go overboard Alan ;-)
> > It makes sense to refuse to build a piece of the kernel if it break's
> > a machine - anything else is a timebomb waiting to explode.
>
> The logical conclusion of that is to replace the entire kernel tree with
>
> #error "compiler or program might have a
Linux Kernel,
(Sorry, had one more change that did not make the patch. this release
contains the corrected patch).
Version 1.1-6 of the Dolphin PCI-SCI (Scalable Coherent Interface) drivers
for Linux kernels 2.2.X and 2.4.X have been posted at
vger.timpanogas.org:/sci. These drivers are
> Alan, I'm sending it to you and not to Linus, as ac1 contains newer
> matroxfb than Linus tree and doing otherwise would make your work harder
> without any reason. But please make sure that Linus's 2.4.2 will contain
> this fix.
I can try. You might want to send him the stuff too though 8)
Finally, after many crashes which I have not been able to capture,
here is two Oops'es which I have transfered by hand from my one
machine to another. Solid lockup I am afraid, only thing working
was Alt-SysRq keys.
# Oops #1 follows
Unable to handle kernel paging request at virtual address
> It makes sense to refuse to build a piece of the kernel if it break's
> a machine - anything else is a timebomb waiting to explode.
The logical conclusion of that is to replace the entire kernel tree with
#error "compiler or program might have a bug. Aborting"
The kernel is NOT some US home
My last comment on this...
It makes sense to refuse to build a piece of the kernel if it break's
a machine - anything else is a timebomb waiting to explode.
I feel politics are at play here...I don't really care who's bug it is -
all I know is using pre 2.96 fixes it and everyone needs to be
1 - 100 of 460 matches
Mail list logo
