Stephen,
Have you or can you run these tests directly against a buffered block
device (bypassing the filesystem) and see if it still behaves correctly?
I have a Java app that does this and 2.4.0-prerelease shows a cumulative
sync() time. As I write more data, sync times take longer and longer
an
Hi,
On Fri, Dec 29, 2000 at 04:25:43PM -0800, Linus Torvalds wrote:
>
> Stephen: mind trying your fsync/etc tests on this one, to verify that the
> inode dirty stuff is all done right?
Back from the Scottish Hogmanay celebrations now. :) I've run my
normal tests on this (based mainly on timing
This BUG() probably means you need to enable DEBUG in mm/slab.c
before you try have OHCI use slab poisoning.
Enable both, or neither, and all should be fine.
- Dave
- Original Message -
From: Miles Lane <[EMAIL PROTECTED]>
To: Linux Kernel <[EMAIL PROTECTED]>; David Brownell <[EMAIL P
> J Sloan wrote:
>
> > Frank Jacobberger wrote:
> >
> > > This is a first for tdfx.o not loading with XFree 4.01.
> > >
> > > All prior kernel build through test13-pre5 would load just fine...
> > >
> > > Strange...
> >
> > Very strange - others on this list, self included,
> > have reported somet
Frank Jacobberger wrote:
> Yes your right... I just haven't noticed... Why doesn't someone fix it?
hehe, my guess is the chief kernel honchos don't play much q3a
Hopefully fixing the makefile problem is on their todo list -
jjs
-
To unsubscribe from this list: send the line "unsubscribe
J Sloan wrote:
> Frank Jacobberger wrote:
>
> > This is a first for tdfx.o not loading with XFree 4.01.
> >
> > All prior kernel build through test13-pre5 would load just fine...
> >
> > Strange...
>
> Very strange - others on this list, self included,
> have reported something a bit different:
>
Frank Jacobberger wrote:
> This is a first for tdfx.o not loading with XFree 4.01.
>
> All prior kernel build through test13-pre5 would load just fine...
>
> Strange...
Very strange - others on this list, self included,
have reported something a bit different:
tdfx.o has not loaded in any kerne
On Fri, 29 Dec 2000, Linus Torvalds wrote:
> > Oblock_super(): what the hell is wait_on_super() doing in fsync_file()?
> > It gives absolutely no warranties - ->write_super() can easily block, so
> > it looks very odd.
>
> A lot of the superblock locking has been odd. It should probably be a
>
> net/network.o(.text+0x5ce78): undefined reference to `prepare_trdev'
> net/network.o(.text+0x5ce88): undefined reference to `prepare_etherdev'
> net/network.o(.text+0x5cee3): undefined reference to `publish_netdev'
My fault. I fed Linus a few things too many trying to get the networking
stuff t
> Hello,
> I received the following error while compiling test13-pre6 .
>
> net/network.o: In function `lecd_attach':
> net/network.o(.text+0x5ce78): undefined reference to `prepare_trdev'
> net/network.o(.text+0x5ce88): undefined reference to `prepare_etherdev'
> net/network.o(.text+0x5cee
Byron Stanoszek <[EMAIL PROTECTED]> writes:
> I narrowed the problem down to a subset of patches from the MM set in
> test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for
> i386), but I'm not yet sure why. test13-pre2 and up work without any problems
> on an Intel cpu (
On Fri, Dec 29, 2000 at 07:36:21PM -0800, Linus Torvalds wrote:
> Maybe your libc is different on the different machines? Normal programs
> shouldn't use segments at all, so I really do not see how this patch could
> matter in the least, even if it was completely and utterly buggy (which is
> not
Ok, I don't think this is an athlon bug, and I think I've figured out what
the problem is. For now, you rtemporary fix is probably fine, I'll clean
stuff up a bit and make a nicer patch available tomorrow.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux
On Fri, 29 Dec 2000, Linus Torvalds wrote:
> Marco d'Itri and everybody else who has seen innd problems (or other
> shared map problems): can you verify that test13-pre6 works for you?
The ->mapping problem seems to be gone in test13-pre5, I'm running this
kernel for over 30 hours now with no gl
On Fri, 29 Dec 2000, Byron Stanoszek wrote:
>
> I narrowed the problem down to a subset of patches from the MM set in
> test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for
> i386), but I'm not yet sure why. test13-pre2 and up work without any problems
> on an Intel c
On Sat, 30 Dec 2000, Daniel Phillips wrote:
> Linus Torvalds wrote:
> >
> > Ok, there's a test13-pre6 out there now, which does a partial sync with
> > Alan, in addition to hopefully fixing the innd shared mapping writeback
> > problem for good. Thanks to Marcelo Tosatti and others..
>
> Aft
On Fri, 29 Dec 2000, Linus Torvalds wrote:
>
> Ok, there's a test13-pre6 out there now, which does a partial sync with
> Alan, in addition to hopefully fixing the innd shared mapping writeback
> problem for good. Thanks to Marcelo Tosatti and others..
I've been noticing a problem with the memo
Linus Torvalds wrote:
>
> Ok, there's a test13-pre6 out there now, which does a partial sync with
> Alan, in addition to hopefully fixing the innd shared mapping writeback
> problem for good. Thanks to Marcelo Tosatti and others..
After the page_cache_release at line 574 of vmscan.c the page is
On Fri, 29 Dec 2000, Alexander Viro wrote:
>
> Two examples: devices and bitmaps-in-pagecache trick. But both belong to
> 2.5, so...
Also, they can easily be done with a private inode, if required. So even
in 2.5.x this may not be a major problem.
> BTW, nice timing ;-) -pre6 appeared 5 minut
On Fri, 29 Dec 2000, Linus Torvalds wrote:
> Al: this changes "mapping->host" to be truly defined as a pointer to the
> inode that owns the mapping. That's how every user actually _used_ the
> host pointer, so this cleans those up to not need any casts. The main
> reason, however, is that we ne
20 matches
Mail list logo
