On Fri, 2 Feb 2001, Martin Diehl wrote:
> Sorry, wasn't clear enough. I've meant, the kernel (PCI stuff) changing
> the BAR bus address in the config space when enabling the device (i.e.
> the bus address value which is used for later mapping). Doing so would
> make the pci_resource_start() value
> We're trying to port some code that currently runs on SGI using the IRIX
> direct I/O facility. From searching the web, it appears that a similar
> feature either already is or will soon be available under Linux. Could
> anyone fill me in on what the status is?
>
> (I know about mapping
On Thu, 01 Feb 2001 01:44:01 Tom Sightler wrote:
> My patches also include changes that should improve this, but I doubt it
> will eliminate the problem. The basic thing here is that it's a horrid
> card
> in regards to performance and most of them only have 8K of buffer, it's
> just
> too
On Fri, 2 Feb 2001, infernix wrote:
> However, the patch hasn't been implemented yet, neither in 2.4.1 or in
> 2.4.1-ac1, because the obvious "HACK,HACK,HACK" sentence is still present :)
> Could someone see to it that this mail reaches the kernel's isdn_ppp.c
> maintainer and get this thing
On Fri, 2 Feb 2001, Manfred wrote:
> What's the purpose of of the irq_2_pin in io_apic.c?
Just for what the comment says: to map our IRQ number to an apic:pin
entity in O(1). It has to be fast! You would have to parse the MP table
otherwise -- see pin_2_irq().
> I assume that I overlook
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote:
> > Can that happen, is that important?
> >
> > Silly question: Why can't we ignore all but the first pin? If we don't
> > enable the additional pins, we don't have to disable them during
> > disable_irq().
>
> Possibly yes -- I haven't seen such a
On Fri, Feb 02, 2001 at 03:51:53PM +, Alan Cox wrote:
> Does this fix the ramfs problem in -ac ?
>
> --- fs/ramfs/inode.c~ Wed Jan 31 22:02:16 2001
> +++ fs/ramfs/inode.c Fri Feb 2 14:51:47 2001
> @@ -174,7 +174,6 @@
> inode->i_blocks += IBLOCKS_PER_PAGE;
>
I have been watching this thread with interest for a while now, but am
wondering about the real-world use of this, given the performance penalty
for write()
As I see it there are two basic cases you are saying this will help in.
1. webservers
2. other fileservers
I also freely admit that I
Chris Mason wrote:
> Hans, decisions about proper compilers should not be made in each
> individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs
broke is broke. If you use reiserfs, DO NOT use 2.96. Period. Nobody gains
by letting a single user make this mistake.
>
There is a rare SMP race in brelse:
1138 void __brelse(struct buffer_head * buf)
1139 {
1140 if (atomic_read(>b_count)) {
1141 atomic_dec(>b_count);
1142 return;
1143 }
1144 printk("VFS: brelse: Trying to free free buffer\n");
1145 }
Hi Daniel,
That is very well known (I posted about it many years ago :) but, as Ingo
(or someone else? maybe sct or Alan? actually, I think it was Andrea)
explained it is not a bug -- for that if() is only for purpose of catching
bad callers (which, in perfect world, shouldn't exist). The whole
> So, did Linus say no? If not, let's ask him with a patch. Quite simply,
> neither we nor the users should be burdened with this, and the patch removes
> the burden.
Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
to stop those being used as well. Oh look you'll
Good day;
I have been having consistent trouble with the last several kernels; all the
test[9-12], 2.4.0 (all patched with reiser) and the 2.4.1 kernel (unpatched)
seem to do this for me. I have devfs enabled as well, but this seems to happen
with or without devfs. I don't believe it happened
On Fri, 2 Feb 2001, Ingo Molnar wrote:
> (hm, dont we have an assert in there to catch ISA IRQs bound to the second
> IO-APIC?) In any case, it would be a very surprising move if anyone added
> a second IO-APIC for the sake of *ISA* devices. This would be truly
> backwards.
It's just the
>I have a D-Link DFE-530TX Rev A, PCI ethernet card, but it refuses
>to work.
>
>I have looked at http://www.scyld.com/network/index.html#pci
>which sugests using the via-rhine driver.
>
>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
On Fri, 2 Feb 2001, Mikael Pettersson wrote:
> > I'm unsure about the K7_NMI_EVENT macro -- I think it should go into
> > include/asm-i386/msr.h, but the comment should remain here. It should get
> > reworded a bit in this case, I suppose, though.
>
> I'd prefer to keep it in nmi.c -- it
Hi Alan, hi others,
source of problems with matroxfb on G450 was revealed: BIOS forgets
to initialize ZORG (0x1C0C) register, and although matroxfb does not use
it, it must contain reasonable value, as it was proved that otherwise it
does not work...
Patch contains:
1) matroxfb_DAC1064.c:
On Wed, Jan 31, 2001 at 06:06:32PM -0200, Rik van Riel wrote:
> On Wed, 31 Jan 2001, Rik van Riel wrote:
>
> > The information page about this bugzilla can be found here:
> >
> > http://www.linux.eu.org/Linux-MM/bugzilla.shtml
>
> OK, I just registered linux-mm.org and changed the
> httpd
On Fri, 2 Feb 2001 [EMAIL PROTECTED] wrote:
> On Wed, Jan 31, 2001 at 06:06:32PM -0200, Rik van Riel wrote:
> > On Wed, 31 Jan 2001, Rik van Riel wrote:
> >
> > > The information page about this bugzilla can be found here:
> > >
> > > http://www.linux.eu.org/Linux-MM/bugzilla.shtml
> >
> >
>Hi,
>
>On Thu, Feb 01, 2001 at 01:28:33PM +0530, [EMAIL PROTECTED] wrote:
>>
>> Here's a second pass attempt, based on Ben's wait queue extensions:
> Does this sound any better ?
>
>It's a mechanism, all right, but you haven't described what problems
>it is trying to solve, and where it is
Hi.
This patch tries to fix the potential rss accounting race where we
change mm->rss without holding page_table_lock.
My reasoning for the correctness of the patch below is as follows.
First I cover the lock pairs added by the patch (top to bottom)
and then the places it does not touch.
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote:
> On Thu, 1 Feb 2001, Andrew Morton wrote:
> +/*
> + * It appears there is an erratum which affects at least the 82093AA
> + * I/O APIC. If a level-triggered interrupt input is being masked in
> + * the redirection entry while the interrupt is
> >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 not copying the exact message.
For example, mine says:
On Fri, 2 Feb 2001, Ingo Oeser wrote:
> No, so have to unlock it also, if you return -ENOSPC.
>
> So the correct fix seems to be:
>
> --- linux/fs/ramfs/inode.c~ Wed Jan 31 22:02:16 2001
> +++ linux/fs/ramfs/inode.cFri Feb 2 14:51:47 2001
> @@ -174,7 +174,6 @@
>
Hey folks,
First off, sorry for spamming all the mailing lists, but I want to make
sure that everyone interested in kiobufs, aio and the like sees this.
Since the mass of discussion going on about kiobufs started, I ran a few
tests of the behaviour of various code when reading from a cached
Files generated by e2fsck in lost+found cannot be removed.
Script started on Fri Feb 2 14:29:55 2001
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sdc1 6356624 2473924 3559796 41% /
/dev/sdc3 2253284 1373532765292 64%
Hi!
> Everyone who says, disk is cheap, ought to donate me one.
> Everyone who says, memory is cheap, has to send me some.
>
> I'm still stuck with a P-133, 56 MB RAM (60-70 ns, some EDO,
> some FPM) and not only Linux but also W2K on a 2.1 and a 0.8 GB
> HDD.
>
> I accept donations in IDE and
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.
On Fri, 2 Feb 2001 [EMAIL PROTECTED] 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?
Pavel
--
I'm
Hi!
This fixes units, and makes format tag: value. Please apply.
Pavel
--- clean/drivers/acpi/cmbatt.c Wed Jan 31 16:14:26 2001
+++ linux/drivers/acpi/cmbatt.c Thu Feb 1 10:55:31 2001
@@ -246,38 +254,32 @@
goto
Hi!
> > It's not an incompatibility with the k7 chip, just bad code in
> > include/asm-i386/string.h.
>
> So you're saying SMP *is* supported on Athlon? Do motherboards exist?
Check today's slashdot ;-).
Pavel
--
I'm [EMAIL
On 2 Feb 01 at 14:44, Richard B. Johnson wrote:
> # rm *
> rm: cannot remove `#1006': Value too large for defined data type
> rm: cannot remove `#1057': Value too large for defined data type
> rm: cannot remove `#1140': Value too large for defined data type
> ls: #588: Value too large for
On Fri, 2 Feb 2001, Helge Hafting wrote:
> "Michael B. Trausch" wrote:
> [...]
> > DevFSd provides symlinks as follows:
> >
> > /dev/ttyS0 = /dev/tts/0
> > /dev/tty0 = /dev/vc/0
> > /dev/pty* = /dev/pty/*
> >
> > Until programs use the new names (e.g., init should tell
On Fri, 2 Feb 2001, Petr Vandrovec wrote:
> On 2 Feb 01 at 14:44, Richard B. Johnson wrote:
>
> > # rm *
> > rm: cannot remove `#1006': Value too large for defined data type
> > rm: cannot remove `#1057': Value too large for defined data type
> > rm: cannot remove `#1140': Value too large for
On Fri, Feb 02, 2001 at 02:51:58PM -0500, Richard B. Johnson wrote:
>
> 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
Hi,
I backup my linux partition once a month from my second IDE drive to an
empty partition
on the first IDE disk. I have about 2.8 Gig to copy, and I use to do the copy.
While cp is copying from the second hard disk to the first hard disk,
I find my system performance
drop VERY
Delta <[EMAIL PROTECTED]> writes:
> While cp is copying from the second hard disk to the first hard disk,
> I find my system performance
> drop VERY sharply. X is sloppy, even bash takes many seconds to
> respond. I using two
> recent IDE disk (Fudjisu 13 gig, Maxtor 20 Gig), so I'm wondering
Ben,
- 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 code for TUX, but i
do not see where it's guaranteed that the process that does the aio does
On Fri, 2 Feb 2001, Delta wrote:
> Hi,
>
> I backup my linux partition once a month from my second IDE drive to an
> empty partition
> on the first IDE disk. I have about 2.8 Gig to copy, and I use /mnt/hd> to do the copy.
>
# cd / ; nice -n 20 tar -clf - . | (cd /mnt/hd; tar -xpf -)
Will
Hi,
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 current_cpu_data before smp_store_cpu_info()
is
> "MBT" == Michael B Trausch <[EMAIL PROTECTED]> writes:
MBT> Is this fixable the "right" way?
On my box, which started its life as a RH7, I've been editing
/etc/security/console.perms as I've discovered problems.
I don't know if this is the right way but thus far I've:
- changed the
I'm not sure whether this problem is related
to 2.4 kernel.
I've installed kernels 2.4.0-prex to 2.4.1 on
the following machines. All are now running 2.4.1.
Judging from my past experience posting here I'm giving much
information
- compaq prolinea p-90 de4x5 driver 1 gig quantum drive cmd 640
Hi there,
I like what you have done here, but there are a few things...
> 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
> +++
At 1:51 pm + 2/2/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?
In general, i think the
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 code for TUX, but i
> do not see where
Linux Kernel,
Version 1.1-5 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 freely
available under the GNU public License and are provided in both
RPM and tar.gz format.
NOTES:
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 ability in the 2.4.0-test series. SYSV shm
> now works only on an internal mounted instance and
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 notail?
Regardless, I'm willing to bet
"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 ability in the 2.4.0-test series. SYSV shm
> > now
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 last
compile, so I thought "make mrproper"
On Fri, 2 Feb 2001, Roeland Th. Jansen wrote:
> ok, just loaded 2.4.1 again with Maciej's patch. works fine but here too
> -- flood ping kills the ethernet stuff in a few seconds. in fact, within
> approx 800 interrupts. the god news is that teh system stays alive, just
> as with Alan's -ac1
Can't view pictures in console with zgv or seejpeg
root@virii:/home/virii/images# seejpeg logo.jpg
svgalib: mmap error in paged screen memory.
root@virii:/home/virii/images# zgv logo.jpg
svgalib: mmap error in paged screen memory.
2.4.1 same problem in 2.4.0
svgalib: mmap error in paged
Kernel version is 2.4.1. For versions of cdrecord later than 1.6.1
(1.8.1 through the latest 1.10 alpha verified), attempting to burn a
CD results in a SCSI error of some kind. Here's some representative
output from a "dummy" burn session with cdrecord-1.9:
Calling:
On Fri, 2 Feb 2001, Ingo Oeser wrote:
> On Fri, Feb 02, 2001 at 08:24:19PM +0100, Mike Galbraith wrote:
> > On Fri, 2 Feb 2001, Ingo Oeser wrote:
> > > No, so have to unlock it also, if you return -ENOSPC.
> > >
> > > So the correct fix seems to be:
> [...]
> > > This currently works for me
On Fri, Feb 02, 2001 at 08:24:19PM +0100, Mike Galbraith wrote:
> On Fri, 2 Feb 2001, Ingo Oeser wrote:
> > No, so have to unlock it also, if you return -ENOSPC.
> >
> > So the correct fix seems to be:
[...]
> > This currently works for me (but using 2.4.0 + dwg-ramfs.patch + this patch)
>
>
Alan Cox wrote:
>
> > So, did Linus say no? If not, let's ask him with a patch. Quite simply,
> > neither we nor the users should be burdened with this, and the patch removes
> > the burden.
>
> Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
> to stop those being
On Fri, 2 Feb 2001, 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
On Fri, 2 Feb 2001, Mark Hahn wrote:
> > I guess I'm doing something stupid, so please can somebody point it out
> > and put me out of my misery ?
>
> don't use cp to copy kernel trees unless you use -s.
>
Thanks for the advice, Mark. I'll give it a go in a minute (got to log off
this box and
On Fri, 2 Feb 2001 16:46:45 + (GMT), Alan Cox <[EMAIL PROTECTED]> wrote:
>> :It is the original one. I'll try with the -69:
>> :
>> With 2.96-69 the reiserfs seems to work well.
>> Sorry for the confusion, I forgot to upgrade the gcc on my machine.
>
> Excellent. Im just glad to
> 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 want to do it anyway?:-) I
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
> 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
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
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
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
> 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:
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
> 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)
> 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
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
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
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
- 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
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
> 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.
> -
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
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, 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
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 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
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
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 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
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:
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:
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
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
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
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 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
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
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
301 - 400 of 460 matches
Mail list logo
