Perhaps an "easy" way to go would be to convert block numbers to
type "block_nr_t", then one could measure the difference that 10's of
nanoseconds make against seeks and reads of disk data.
Obviously the effect would be greater on ramdisks, but on computers with
equivalent generation hard disk
On Thu, Aug 31, 2000 at 02:52:56PM +0200, you [[EMAIL PROTECTED]] claimed:
>
> Does also include the build number (i.e. the first part of
> UTS_VERSION) ? Is it resilient to patches where, by accident,
> EXTRAVERSION or such hasn't been incremented ? Will people always
Speaking of patches, it wo
Michael Bielicki <[EMAIL PROTECTED]> writes:
> Was done but Informix DS 7.3 still sees no shared memory. Either I
> did something wrong in the compile or I don't know. I am preparing
> straces since two members of the list offered to look into
> them. What I also don't understand is the ouput of
"Richard B. Johnson" wrote:
>
> On Thu, 31 Aug 2000, Petko Manolov wrote:
>
> > I realy would like to see this code in use ;-)
>
> After you test it **THOUROUGHLY**, send a patch to Linus. I
> recommend testing it in a user-mode program with all kinds of
> sizes/shapes/lengths/offsets, etc., an
We are pleased to announce that the TUX kernel-space HTTP-subsystem is
available for download at:
ftp://ftp.redhat.com/pub/redhat/tux/tux-hawaii/
WARNING: this is a developer-only, alpha release. The 1.0 'consumer'
release will happen by the end of September. This release is useless to
On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
> Nathan Paul Simons wrote:
> > As for the argument of putting it in the kernel being more robust and
> > idiot-proof, well, if someone can't keep three files and one directory
> > straight for each different configuration of
On Fri, Sep 01, 2000 at 11:01:30AM +0200, Andi Kleen wrote:
> On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
> > I for one can't even keep two files straight - my kernel is forever
> > getting out of synch with my System.map. Of course, I may be the only
> > person that has ever
On Thu, 31 Aug 2000, Jonathan Stanford wrote:
[kernel 2.2.16]
> i was running at 3.4 MB/sec
> now it's as high as 27 MB/sec
>
Then you're using UDMA66. I have a VIA KX133 which also does UDMA66, and a
Maxtor 7.2k rpm 8GB is doing 29MB/s. I didn't even need to compile in specific
VIA chipset su
> " " == Michael Riepe <[EMAIL PROTECTED]> writes:
>> Ugh. In that case, my personal preference would be to make
>> nlm_release_file() grab the semaphore, then call another
>> routine to do f_count-- and possible file cleanup which could
>> also be called by nlmsvc_traverse_sh
Hi,
I have the following configuration
--
||| |
¤ eth1 || |
| eth0 ¤ -- ¤ eth0 |
¤ eth2 || |
||| |
-----
On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
>
> I for one can't even keep two files straight - my kernel is forever
> getting out of synch with my System.map. Of course, I may be the only
> person that has ever had this happen to them. ;-) I am all for
> idiot-proofing thi
Stephen, could you have a moment to look at the struct buffer_head {}
alignment matters ? And possible configure time change to make the
block number possibly a 'long long' variable ?
Changeing field order might be doable now, while I definitely think that
changeing blocknumber vari
Hello.
Following patch against 2.4.0-test7 fixes returning of errors from
ext2_new_inode(). Currenly if ext2_new_inode() failed EIO was returned
from functions like ext2_create() which is bad as it can fail also
with EDQUOT and such.
Ho
work , the kernel module builds normally but when I run X with dri
uncommented X dies with a message "drm vers 1.1 expected 1.01" or something
.
Any Ideas?
--
screw you guys, I'm going $HOME
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
On Fri, 1 Sep 2000, Linda Walsh wrote:
> Perhaps an "easy" way to go would be to convert block numbers to
> type "block_nr_t", then one could measure the difference that 10's of
> nanoseconds make against seeks and reads of disk data.
True for DOS.
On Linux, most file operations are done in R
Sorry, I've no idea about the ext2 and fs implementation.
However did you read the comment below and convince yourself that 'err' is
always set correctly?
I'm just asking because you don't mention it and no patch to
ext2_new_inode that makes it set err correctly is provided. It could be
the comme
Hi Michael,
It is better to assume that he has done the checks and then do the checks
to convince yourself (as they say in russia "doverjaj no proverjaj" -
"trust but always double-check").
So, I now went fs/ext2/ialloc.c and did that for you - ext2_new_inode()
does indeed set err accordingly an
On Fri, 01 Sep 2000, I wrote:
> I have dri working fine in my voodoo3 at home with the above config.In
> work , the kernel module builds normally but when I run X with dri
> uncommented X dies with a message "drm vers 1.1 expected 1.01" or
> something
> .
> Any Ideas?
>
I have the X server o
FIRST:
Aug 31 17:43:26 giulia kernel: Oops: 0002
Aug 31 17:43:26 giulia kernel: CPU:0
Aug 31 17:43:26 giulia kernel: EIP:0010:[sys_write+66/292]
Aug 31 17:43:26 giulia kernel: EFLAGS: 00010206
Aug 31 17:43:26 giulia kernel: eax: bc4a7800 ebx: 20485b1b ecx: 080c380c
edx: 0018
Au
> > Since 2.2.17 isnt out yet I've released 2.2.18pre1 versus 2.2.17pre20. So
> > you need to grab 2.2.16 then apply the 2.2.17pre20 patch then the 2.2.18pre
> > patch of choice.
>
> Well, I'm asking again, as usual, are you planning to integrate
> kernel-space NFSv3? I'd appreciate if you did.
On Fri, Sep 01 2000, Rene Mayrhofer wrote:
> Ok, now I think to know what you are meaning: The program locking the door
> should stay active until the CD-ROM should be unlocked, right ?
No, not necessarily. What matters is the open count of the drive. Currently
it will not unlock a tray, that is
On Thu, 31 Aug 2000, Erik McKee wrote:
> Hello!
>
> This is one of my first posts here, so try to be gentle, please ;)
>
> Seems like if a thread which shares a VM with all the other threads of the
> same family does an execve, the following would be likely to occurr, using
> the standard defin
Linus,
Here is a patch to take the SYBA IDs out from the middle of the LAVA
IDs. It makes for easier reading when you're trying to find out what
Lava device IDs are listed.
Tim.
*/
--- linux/include/linux/pci_ids.h.orig Tue Aug 29 17:17:33 2000
+++ linux/include/linux/pci_ids.h Fri Sep
On Thu, 31 Aug 2000, Alan Cox wrote:
>
> Since 2.2.17 isnt out yet I've released 2.2.18pre1 versus 2.2.17pre20. So
> you need to grab 2.2.16 then apply the 2.2.17pre20 patch then the 2.2.18pre
> patch of choice.
One day I hope you'll explain to us why this is not 2.2.17pre21...
Either you are
On Fri, Sep 01, 2000 at 12:05:03PM +0100, Alan Cox wrote:
> > > Since 2.2.17 isnt out yet I've released 2.2.18pre1 versus 2.2.17pre20. So
> > > you need to grab 2.2.16 then apply the 2.2.17pre20 patch then the 2.2.18pre
> > > patch of choice.
> >
> > Well, I'm asking again, as usual, are you pla
On Thu, 31 Aug 2000, J. Dow wrote:
> > Ouch... Why did he do them (links to directories, that is), in the
> > first place?
>
> Since you asked, but I am warning you that you don't want to know
> Well, maybe you do - there is a project to port UNIXy tools to every
> platform in existance. W
Andi Kleen wrote:
> What you need is a bootloader than can read uncompressed vmlinux directly,
> and use that for booting. Then you can always directly extract the System.map
> out of the vmlinux using nm or gdb.
And then pass this information to the soon to be running system via e.g.
an initrd
Gidday!
I was just flicking through the Kernel Traffic archives, did a brief skim,
and was alarmed to find my name there. It was in this thread, so I decided
it was worth a second look for my .00015*10^-9 nanoseconds of
fame. I've updated the press release itself below.
There are othe
On Fri, Sep 01, 2000 at 02:04:44PM +0200, [EMAIL PROTECTED] wrote:
> Andi Kleen wrote:
> > What you need is a bootloader than can read uncompressed vmlinux directly,
> > and use that for booting. Then you can always directly extract the System.map
> > out of the vmlinux using nm or gdb.
>
> And
Jan-Benedict Glaw wrote:
> On Thu, Aug 31, 2000 at 04:26:55PM +0200, [EMAIL PROTECTED] wrote:
> > But what about GRUB, LOADLIN, SILO, MILO, ... ?)
>
> I've written scripts do copy any useful piece of (debug) info to
> /boot. To cope with MILO, you can use:
Actually, this was a trick question, so
> One day I hope you'll explain to us why this is not 2.2.17pre21...
> Either you are sure pre20 is going to be the official 2.2.17,
> or I'm missing something.
The 2.2.18pre1 changes are higher risk problems to fix. 2.2.17pre20 is extremely
solid. Its probably the most solid 2.2 kernel so far o
In article <[EMAIL PROTECTED]>,
Andi Kleen <[EMAIL PROTECTED]> wrote:
>The big problem with the raid patches is that there is no way back for your
>raid array, unless somebody adds a noconv modus to raidutils and support into
>the kernel to keep the old super block version. It also requires tools
[EMAIL PROTECTED] (Matthias Andree) writes:
>Alan Cox <[EMAIL PROTECTED]> writes:
>> Since 2.2.17 isnt out yet I've released 2.2.18pre1 versus 2.2.17pre20. So
>> you need to grab 2.2.16 then apply the 2.2.17pre20 patch then the 2.2.18pre
>> patch of choice.
>Well, I'm asking again, as usual, a
Andi Kleen wrote:
> I'm not sure I understand the question. It would basically work like
> booting in BSD or most other Unixes: the bootloader knows ext2 and
> reads a filename that you pass as a command line option or a default
> from /. That file name would be available in the environment that i
On Fri, Sep 01, 2000 at 02:23:57PM +0200, [EMAIL PROTECTED] wrote:
> I don't see the advantage over Alan's proposal of simply adding the
> config data to the bzImage or whatever is the most common format on
> the respective platform. You still have the same fundamental problem
> to solve (i.e. acc
> On Fri, Sep 01, 2000 at 02:23:57PM +0200, [EMAIL PROTECTED] wrote:
> > I don't see the advantage over Alan's proposal of simply adding the
> > config data to the bzImage or whatever is the most common format on
> > the respective platform. You still have the same fundamental problem
> > to solve
On Thu, Aug 31, 2000 at 09:50:35PM -0700, Richard Henderson wrote:
> On Fri, Sep 01, 2000 at 12:16:38AM +0300, Matti Aarnio wrote:
> > Also (I recall) because GCC's 'long long' related operations
> > and optimizations have been buggy in past, and there is no
> > sufficient experience t
Here is a patch for 2.2.18pre1 which:
- removes broken Timedia support (see 2.4 for the correct version)
- adds Boca Research IOPPAR support
- adds Oxford Semi OX16PCI954 and OX12PCI840 support
Tim.
*/
diff -durN linux-2.2.18pre1/drivers/misc/parport_pc.c linux/drivers/misc/parport_pc.c
--- lin
Alan Cox <[EMAIL PROTECTED]> writes:
> People would appreciate lots of things but stability happens to come first.
> Thats why its primarily focussed on driver stuff not on revamping the
> internals. Right now Im not happy with the nfsv3 stuff I last looked at and
> it seems to still contain thi
On Fri, Sep 01, 2000 at 02:44:04PM +0200, Andi Kleen wrote:
> > To my knowlege it's only been speed related issues, not
> > correctness issues, that have been the cause for the
> > fear and loathing of long long.
>
> There are several parts of XFS which do not compile correctly with gcc
> 2.95.2,
On Fri, Sep 01, 2000 at 04:01:43PM +0300, Matti Aarnio wrote:
> On Fri, Sep 01, 2000 at 02:44:04PM +0200, Andi Kleen wrote:
> > > To my knowlege it's only been speed related issues, not
> > > correctness issues, that have been the cause for the
> > > fear and loathing of long long.
> >
> > There
Chris Evans writes:
>
> On Thu, 31 Aug 2000, Tigran Aivazian wrote:
>
> > Actually, microcode driver checks CAP_SYS_RAWIO only on open() so it would
> > allow access to the receiver of fd even he has no CAP_SYS_RAWIO
> > privilege. Hmmm, maybe I should put it back into write() method, as Linus
>
Hi,
I have set the HZ constant to 1024 to increase the select resulution.
But the results of my measurements are not
as expected. I have a cyclical task (using select for timing) that
inverts a parallel port bit in each
cycle. I measure the high time with an oszillograph.
Here are my results:
1
Alan Cox wrote:
> My goal would be to ensure that the bootloader didnt need to be modified.
Yes, I was commenting on Andi's proposal. I think it's very important to
avoid the need for boot loader modifications - there are simply too many
of them nowadays.
> As to the tool argument - looking for
Andi Kleen wrote:
> I just don't see much advantage in a bzImage anymore, given the disk sizes
> of modern computers.
My floppies are still 1.44MB ...
> For kernel debugging I prefer to have an unpacked vmlinux with symbol table.
Agreed, it's more elegant.
> Would it be that hard to make lilo
On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote:
> > ( Not 'unsigned long long' )
>
> The shift on pbm_offset operates on long long.
Uh, somehow I thought the reference was about bh->b_blocknr;
Ok, never mind.
> The previous analysis was not quite right though (
Hi alan.
Here is a patch for 2.2.18pre1 which:
- fix: cannot build microcode.c
--- linux/include/linux/smp.h.orig Thu Jun 3 03:29:28 1999
+++ linux/include/linux/smp.h Fri Sep 1 22:51:39 2000
@@ -80,7 +80,7 @@
#define smp_threads_ready 1
#define kernel_lock()
attention everyone,
the assumption that people who use raid or nfs always use a patched kernel
is not true.
in many cases it is not trivial to find the newest patches and tools to go
with them (documentation limitations) and in other cases the stock stuff
seems to work so people don't realize th
On Fri, 1 Sep 2000, Alan Cox wrote:
> I'd love to have raid 0.90, nfsv3 and the new ide stuff in but I
> cannot see a path for that without breaking a supposedly stable
> product for other people which is simply not acceptable.
>
raid i can understand considering it's a 'no way back' thing. the
On 1 Sep 2000, Matthias Andree wrote:
> Does including knfsd v3 break v2? Is not NFS v3 a compile-time option? I
> would not object if it was tagged "EXPERIMENTAL".
it is. asui the NFS patches are bugfixes/improvements on the existing
stock V2 knfsd, and the feature add v3 is pretty much indepe
Date:Fri, 1 Sep 2000 12:47:44 +0200 (MESZ)
From: "Dr. Michael Weller" <[EMAIL PROTECTED]>
Sorry, I've no idea about the ext2 and fs implementation.
However did you read the comment below and convince yourself that 'err' is
always set correctly?
I looked at it and was convi
Jens Axboe wrote:
> > I always though about issuing some single call to lock or unlock the drive
> > (e.g. setcd), but I never thought about this. What do I have to do to make
> > this possible ? Could you give me some hint on how to allow root to unlock
> > it in a clean way ? I wouldn't be very
>Also, I might be wrong, but maybe you should submit things to Alan, not
>Linus, could be it suffices to post them here though.
>
> Actually, life is a little bit easier when you give the subsystem
> maintainer a chance to submit patches to Linus.
For 2.2.x you can submit me stuff. Im n
Here is a patch to fix a small bug with ppdev.
Tim.
*/
--- linux/drivers/char/ppdev.c.typo Fri Jul 14 11:39:20 2000
+++ linux/drivers/char/ppdev.c Fri Sep 1 15:47:52 2000
@@ -179,7 +179,7 @@
wrote = parport_write (pp->pdev->port, kbuffer, n);
- if (wrote <
On Fri, 1 Sep 2000, Matti Aarnio wrote:
> On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote:
> > > ( Not 'unsigned long long' )
> >
> > The shift on pbm_offset operates on long long.
>
> Uh, somehow I thought the reference was about bh->b_blocknr;
> Ok, never mind.
>
>
While working on a serial driver for AMBA-style serial ports (an ARM
special thing), and I've just spotted an overrun bug in the overrun
code of the 16x50 serial driver:
if (*status & UART_LSR_OE) {
/*
* Overrun is special, since it's
* re
From: Russell King <[EMAIL PROTECTED]>
Date: Fri, 1 Sep 2000 16:23:39 +0100 (BST)
At the marked line (! - line 647), what if flip.count is equal to
TTY_FLIPBUF_SIZE? Surely we're writing to a character outside the
flag_buf_ptr array? If that is the case, should we not move this
I have discovered a problem with the Linux 2.4.0 VFAT filesystem. Short
names that have mixed case do not retain their case on the VFAT
filesystem. This has mostly worked in the past on 2.1.x, 2.2.x, 2.3.x
kernels. I am currently testing 2.4.0-test8-pre1. The filsystem was
mounted with the follo
[Apologies in advance for polluting the linux-kernel with this, but I felt
that Mr. Stone's interesting contribution deserved a response from "the
other side" -- and that my response may have an impact on the people
providing the source information, namely the kernel developers.]
As a working
David Lang <[EMAIL PROTECTED]> said:
> attention everyone,
>
> the assumption that people who use raid or nfs always use a patched kernel
> is not true.
>
> in many cases it is not trivial to find the newest patches and tools to go
> with them (documentation limitations) and in other cases the s
On Fri, 1 Sep 2000, Gaines, Brett W wrote:
> I have discovered a problem with the Linux 2.4.0 VFAT filesystem. Short
> names that have mixed case do not retain their case on the VFAT
> filesystem. This has mostly worked in the past on 2.1.x, 2.2.x, 2.3.x
> kernels. I am currently testing 2.4.0-t
On Fri, Sep 01, 2000 at 12:05:03PM +0100, Alan Cox wrote:
> People would appreciate lots of things but stability happens to come first.
> Thats why its primarily focussed on driver stuff not on revamping the
> internals. Right now Im not happy with the nfsv3 stuff I last looked at and
> it seems
With all the talk about bugs and slowness on a 386/486/586 -- does anyone
think those platforms will have multi-T disks hooked up to them?
Now bugs in the compiler are a problem, but at some point in the future, one
would hope we could move to a compiler that can handle division w/no
problems.
Hi!
> > CODA's local caching is pretty much neccessity: you can't have
> > read/write server in userland on localhost at smaller granularity due
> > to deadlock issues.
>
> For distributed filesystem - yes (but not necessary). For other kinds of
> stuff - provably not true.
Okay, how do you imp
> With all the talk about bugs and slowness on a 386/486/586 -- does anyone
> think those platforms will have multi-T disks hooked up to them?
Yes. The poor handling of 64bit numbers hasnt gone away on PentiumII or Athlon
as far as I can tell
-
To unsubscribe from this list: send the line "unsub
Linda Walsh wrote:
> It may not matter too too much, but blocks are being passed around as
> 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T
> disk size. Probably don't need to worry about this today, but in a few
> years? Should we be changing the internal interfaces to
> What I'd like to add is: while we're at it, how about losing the 512
> byte magic multiplier and go with the filesystem block size? That way
> Ext2 file size automatically goes up by a factor of 8 every time we
> manage to double the filesystem block size (blocksize*2 and triple
> indirect => 2
On Fri, Sep 01, 2000 at 09:16:23AM -0700, Linda Walsh wrote:
> With all the talk about bugs and slowness on a 386/486/586 -- does anyone
> think those platforms will have multi-T disks hooked up to them?
Propably not.
...
> If you changed all the block number definitions to use 'block_nr_
On Fri, 1 Sep 2000, Alan Cox wrote:
> > With all the talk about bugs and slowness on a 386/486/586 -- does anyone
> > think those platforms will have multi-T disks hooked up to them?
>
> Yes. The poor handling of 64bit numbers hasnt gone away on
> PentiumII or Athlon as far as I can tell
41-bit
On Fri, 1 Sep 2000, Daniel Phillips wrote:
> Linda Walsh wrote:
> > It may not matter too too much, but blocks are being passed around as
> > 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T
> > disk size. Probably don't need to worry about this today, but in a few
> > y
On Fri, Sep 01, 2000 at 12:09:23AM -0700, Linda Walsh wrote:
> Perhaps an "easy" way to go would be to convert block numbers to
> type "block_nr_t", then one could measure the difference that 10's of
> nanoseconds make against seeks and reads of disk data.
That's not the issue. The issue is t
On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote:
> So what do you propose to use when a long long division is needed (after
> much thought and considering all alternatives etc.etc.) ?
Link against libgcc, what else?
We should have been doing that since the beginning instead of
making
Hello Ingo , OK wise guy . Where is the description of what it
does ? I'd really like to know . Tia, JimL
++
| James W. Laferriere | System Techniques | Give me VMS |
| Network
> 41-bit filesize should be enough for the 32-bit machines.
>
> By the time people start using >41-bit files, don't you think
> they'll have an AMD-64, PPC or Merced CPU to handle the bigger
> file sizes?
Nope
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
Has anyone got the Nvidia 0.9.4 (for XFree86 4.0.1) to compile under a
2.4.0-testX kernel (I'm using test7)?
I've patched my kernel for the KT133 agpgart, and now can't use it!
(knowingly!)
Regards,
Duncan
--
http://www.3dnow.org.uk
-
To unsubscribe from this list: send the line "unsubscri
Hello Alan (& Others) , How about describing what it breaks ?
I know that invoking the God Linus's name can just get people
to back down . So I ask for myself as well as others ...
what , where , when , why , who .Hth , JimL
On Fri, 1 Sep 2000, Alan Cox wro
Hello,
I noticed that with kernel 2.4.0-test7 the system seems
to use all cpu capasity although there are only a few
processes running and none of them use a lot of cpu capasity..
CPU states: 0.0% user, 100.0% system, 0.0% nice, 0.0% idle
it always shows 99.0% - 100.0%..
is this a bug in the
Hi Daniel, anyone.
I am not a lawyer and I am not a marketing manager, but I think there
are several things that need fixing. Most of these are differences that
I think stand out when comparing your draft with the KDE press releases
for their KDE2.0 betas (those being the only press releases I've
> On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote:
> > So what do you propose to use when a long long division is needed (after
> > much thought and considering all alternatives etc.etc.) ?
>
> Link against libgcc, what else?
As also does anyone who does solaris drivers (x86 or sparc
On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote:
> The previous analysis was not quite right though (%cl is actually loaded,
> just %eax gets bogus input from the long long shift)
Perhaps, but it's sure not obvious:
bh->b_blocknr = (long)mp->pbm_bn +
(mp->pbm_
On 1 Sep 00 at 20:29, Tuomas Silen wrote:
> CPU states: 0.0% user, 100.0% system, 0.0% nice, 0.0% idle
>
> it always shows 99.0% - 100.0%..
>
> is this a bug in the kernel or something else?
Bug in kernel. Do not use SMP kernel on UP motherboard...
> if it's a bug is it already fixed in test
Since 2.2.17 isnt out yet I've released 2.2.18pre2 versus 2.2.17pre20. So
you need to grab 2.2.16 then apply the 2.2.17pre20 patch then the 2.2.18pre
patch of choice.
Ok 2.2.18pre2 merges the large stuff that doesnt interfere with other parts
of the kernel and some small fixes that are needed. M
Hi,
Any of you tried copying a 2G file in the same (ext2) filesystem? It
starts swapping like mad and generally behaves indecently, despite the
huge 1024M of RAM it has.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
The last non-panic message on screen is:
IPv6 v0.8 for NET4.0
The panic reason is "attempting to kill init".
Has anyone else had this problem?
Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at h
Alexander Viro wrote:
>
> On Fri, 1 Sep 2000, Daniel Phillips wrote:
>
> > Linda Walsh wrote:
> > > It may not matter too too much, but blocks are being passed around as
> > > 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T
> > > disk size. Probably don't need to worry a
> address 68736170
> address 33312051
> address 3331203d
The kernel is using ASCII text as pointers. Convert the above:
"pash"
"Q 13"
"= 13"
Try different kernels and different compilers.
The hardware is probably OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> Any of you tried copying a 2G file in the same (ext2)
> filesystem? It starts swapping like mad and generally behaves
> indecently, despite the huge 1024M of RAM it has.
http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
I'm working on these issues a
On Fri, Sep 01, 2000 at 10:34:19AM -0700, Matthew Jacob wrote:
> > On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote:
> > > So what do you propose to use when a long long division is needed (after
> > > much thought and considering all alternatives etc.etc.) ?
> >
> > Link against libgc
Alan Cox writes:
> o Make vfat use the same generation rules as (H. Kawaguchi,
> in windows 9xChip Salzenberg)
I doubt this is obviously correct. The last time this issue
came up, it was discovered that Windows 9x does not use the
same generatio
>
> Or use --print-libgcc-file-name:
>
> `gcc --print-libgcc-file-name`
>
> where are the options normally used to compile code (ie, for example
> on machines that optionally do not have a floating point use, adding
> -msoft-float would select the libgcc.a that was compiled with -msoft-
On Fri, Sep 01, 2000 at 12:01:39PM -0700, Matthew Jacob wrote:
> >
> > Or use --print-libgcc-file-name:
> >
> > `gcc --print-libgcc-file-name`
> >
> > where are the options normally used to compile code (ie, for example
> > on machines that optionally do not have a floating point use, add
> >
> > Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back
> > at Auspex in '93. ...Guess the compiler driver has gotten smarter since.
> > You know how it goes- you do a trick once- you don't change it for years...
>
> According to the ChangeLog of the 2.7.2.3 compile
On Fri, Sep 01, 2000 at 11:40:31AM +0200, Trond Myklebust wrote:
[...]
> > nlm_release_file() *does* grab the semaphore. That's the
> > problem.
>
> Which is why I'm proposing a solution: to split it into 2 functions.
>1st function does the semaphore manipulations and calls
>2n
I'm looking for anyone that has merged the international crypto patches
with Red Hat kernel rpm's.
I've basically gotten the patch to apply cleanly, but then the build
completely fails during module building. I don't have the know how to fix
things.
Thanks for any information.
I'm currently
> > Any of you tried copying a 2G file in the same (ext2)
> > filesystem? It starts swapping like mad and generally behaves
> > indecently, despite the huge 1024M of RAM it has.
>
> http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
this patch works very nicely. it's still a little timid at
sw
Daniel Stone wrote:
>
> Gidday!
{SNIP}
>-> Multimedia
> * Faster multimedia with specially designed video acceleration drivers. In
>combination with the new release of the X Windows System, Linux includes drivers to
>take full advantage of your accelerated video card (nVidia and 3Dfx
From: Daniel Phillips <[EMAIL PROTECTED]>
Date:Fri, 01 Sep 2000 20:49:14 +0200
Curiously, this field is measured in 512 byte units, giving a 2TB Ext2
filesize limit. That's starting to look uncomfortably small - I can
easily imagine a single database file wanting to be big
On Fri, 1 Sep 2000, Rik van Riel wrote:
> On Fri, 1 Sep 2000, Tigran Aivazian wrote:
>
> > Any of you tried copying a 2G file in the same (ext2)
> > filesystem? It starts swapping like mad and generally behaves
> > indecently, despite the huge 1024M of RAM it has.
>
> http://www.surriel.com/pa
Hi.
AFAICS, the line removed below is redundant. Comments?
--- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
+++ linux/mm/memory.c Fri Sep 1 22:00:16 2000
@@ -986,7 +986,6 @@
out_unlock:
spin_unlock(&mapping->i_shared_lock);
/* this should go into ->truncate */
On Fri, 1 Sep 2000, Chris Evans wrote:
> On Fri, 1 Sep 2000, Rik van Riel wrote:
> > On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> >
> > > Any of you tried copying a 2G file in the same (ext2)
> > > filesystem? It starts swapping like mad and generally behaves
> > > indecently, despite the huge 10
1 - 100 of 195 matches
Mail list logo
