On Wed, Jan 10, 2001 at 02:47:35PM +, Stephen C. Tweedie wrote:
Hi,
On Tue, Jan 09, 2001 at 03:06:35PM +0100, Andrea Arcangeli wrote:
On Tue, Jan 09, 2001 at 07:41:21AM -0600, Jesse Pollard wrote:
Not exactly valid, since a file could be created in that "pinned" director
On Wed, Jan 10, 2001 at 06:54:45AM +, Russell King wrote:
This is an internal kernel data structure. Do you know of some program
No, it isn't, that's the whole point.
that breaks as a result of this?
(spotted by Andi) util-linux-2.10o/mount/nfs_mount4.h:
struct nfs3_fh {
On Wed, Jan 10, 2001 at 12:47:17AM -0500, Alexander Viro wrote:
Chris, I seriously suspect that it's not that simple (read: trace is a
BS). 0x20b is just too large for filldir().
[..]
and we don't trigger them... Fsck knows. copy_to_user() and put_user() should
not be able to screw the kernel
On Wed, Jan 10, 2001 at 12:28:38PM -0500, Alexander Viro wrote:
That's precisely what I've already done. grep for IS_DEADDIR() and notice
Fine ;)
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
On Wed, Jan 10, 2001 at 10:46:07AM -0700, Eric W. Biederman wrote:
Why do we even want to do reverse page tables?
It seems everyone is assuming this is a good thing and except for being
I'm not assuming it's a good thing, but I believe it's something to try.
My impression with the MM stuff
On Wed, Jan 10, 2001 at 10:09:22PM +, Russell King wrote:
Andrea Arcangeli writes:
Furthmore
the cast of data to a struct should work on all architectures as far as C is
concerned (if you then run
On Thu, Jan 11, 2001 at 11:31:21AM +0100, Udo A. Steinberg wrote:
CONFIG_MK7=y
I'm looking into it.
Andrea
-
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 http://www.tux.org/lkml/
On Thu, Jan 11, 2001 at 06:36:05PM +0100, Andrea Arcangeli wrote:
On Thu, Jan 11, 2001 at 11:31:21AM +0100, Udo A. Steinberg wrote:
CONFIG_MK7=y
I'm looking into it.
The fxsr fixes from 2.4.1-pre1 allows athlon to correctly use FXSR too (when
nofxsr isn't passed to the kernel of course
On Thu, Jan 11, 2001 at 06:46:45PM +0100, Andrea Arcangeli wrote:
Until I fix the 3dnow code to use the i387.c library please workaround
this way:
--- ./arch/i386/config.in.~1~ Thu Jan 11 17:52:05 2001
+++ ./arch/i386/config.in Thu Jan 11 18:38:29 2001
@@ -109,7 +109,7
On Thu, Jan 11, 2001 at 07:22:03PM +0100, Trond Myklebust wrote:
[..] Are there any
alignment requirements on them?
On some arch int can be read only at a sizeof(int) byte aligned address
(details in my example in reply to Russell).
Andrea
-
To unsubscribe from this list: send the line
On Thu, Jan 11, 2001 at 07:30:49PM +0100, Trond Myklebust wrote:
OK. In that case my patch, would just be amended to eliminate the
redundant comparison as is the case below.
This patch looks fine w.r.t. alignment but given the below seems called
at runtime (not just at mount time) for
On Thu, Jan 11, 2001 at 06:48:21PM +0100, Andrea Arcangeli wrote:
Ah no, I even better, just pass `nofxsr` to the 2.4.1-pre2 kernel. (no
need to recompile)
Ok here the right fix against 2.4.1-pre2 so now you can use 3dnow and fxsr
at the same time (and nofxsr can still dynamically disable fxsr
On Thu, Jan 11, 2001 at 02:01:58PM -0500, [EMAIL PROTECTED] wrote:
Hi,
The most puzzling thing is happeneing. I have compiled a vanillat 2.2.18
kernel with scsi aic7xxx compiled in, 3com network support. (nothing fancy
no sound, no isdn, video, etc...)
I installed this kernel on a
On Thu, Jan 11, 2001 at 08:16:27PM +0100, Andrea Arcangeli wrote:
On Thu, Jan 11, 2001 at 02:01:58PM -0500, [EMAIL PROTECTED] wrote:
Hi,
The most puzzling thing is happeneing. I have compiled a vanillat 2.2.18
kernel with scsi aic7xxx compiled in, 3com network support. (nothing fancy
On Thu, Jan 11, 2001 at 03:36:13PM -0600, Jens Petersohn wrote:
My appologies if this has been asked before. I'm looking for
Ingo Molnar's RAID patch for 2.2.18-final. I tried applying A2, but
it has a number of conflicts in raid1.c which I cannot resolve in
my meager spare time.
I had to
On Thu, Jan 11, 2001 at 06:08:21PM -0800, Linus Torvalds wrote:
Could people with Athlons please verify that pre3 works for them?
It works fine.
It also makes the fxsr disable act the same way the TSC disable does.
Note that there was a precise reason for not implementing it as the TSC
On Tue, Jan 09, 2001 at 07:38:28PM +0100, Ingo Molnar wrote:
On Tue, 9 Jan 2001, Jens Axboe wrote:
ever seen, this is why i quoted it - the talk was about block-IO
performance, and Stephen said that our block IO sucks. It used to suck,
but in 2.4, with the right patch from Jens,
On Wed, Jan 10, 2001 at 12:34:35AM +0100, Jens Axboe wrote:
Ah I see. It would be nice to base the QUEUE_NR_REQUEST on something else
than a static number. For example, 3000 per queue translates into 281Kb
of request slots per queue. On a typical system with a floppy, hard drive,
and CD-ROM
On Thu, Jan 11, 2001 at 08:26:04PM -0800, Linus Torvalds wrote:
On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
Note that there was a precise reason for not implementing it as the TSC disable
(infact at first in 2.2.x I was clearing the bigflag in x86_capabilities too).
The reason
On Fri, Jan 12, 2001 at 11:42:32AM -0500, Richard A Nelson wrote:
On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
It doesn't make much sense to me to put the "can_I_use" global information in
the per-cpu slots, that's obviously the wrong place for it. We simply need to
add a
On Fri, Jan 12, 2001 at 09:35:14AM -0800, Linus Torvalds wrote:
On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
On Fri, Jan 12, 2001 at 11:42:32AM -0500, Richard A Nelson wrote:
Its fine either way on current x86 and many other platforms, but falls
on its face in the presence
On Fri, Jan 12, 2001 at 10:35:24AM -0800, Linus Torvalds wrote:
Andreas argument was that earlier kernels weren't consistent, and as
such we shouldn't even bother to try to make newer kernels consistent.
We would be better off reporting our internal inconsistencies the way
earlier kernels
On Sat, Jan 13, 2001 at 08:10:33PM +0100, Sasi Peter wrote:
Jan 13 01:58:17 iq kernel: probable hardware bug: clock timer
configuration lost - probably a VIA686a.
Jan 13 01:58:17 iq kernel: probable hardware bug: restoring chip
configuration.
I get these, do not know why. MB is abit BH6,
On Sun, Jan 14, 2001 at 09:31:29AM -0500, Todd M. Roy wrote:
Andrea,
Sorry to say but lvm 0.9.1-beta1 still segfaults
at the same place, line 140 of pv_read_all_pv_of_vg.c
pv_this is still null.
BTW, I can easily reproduce. I was near to go into it yesterday but got
interrupted by other
On Sun, Jan 14, 2001 at 05:32:34PM +0100, Andrea Arcangeli wrote:
BTW, I can easily reproduce. I was near to go into it yesterday but got
interrupted by other issues (like the merging of the 0.9.1-beta1 kernel driver
and extraction of the strictly necessary fixes from the 0.9.1-beta1 userspace
On Tue, Jan 16, 2001 at 11:04:45AM -0800, Theodore Y. Ts'o wrote:
HJ Lu recently pointed me at a potential locking problem
try_to_free_inodes(), and when I started proding at it, I found what
appears to be another set of SMP locking issues in the dcache code.
(But if that were the case, why
On Thu, Jan 18, 2001 at 08:49:38AM -0800, Linus Torvalds wrote:
state. However, the fact is that you _need_ the persistency of a socket
option if you want to take advantage of external programs etc getting good
behaviour without having to know that they are talking to a socket.
I'm all for
On Thu, Jan 18, 2001 at 10:59:11PM +0300, [EMAIL PROTECTED] wrote:
Hello!
I'm all for TCP_CORK but it has the disavantage of two syscalls for doing the
MSG_MORE was invented to allow to collapse this to 0 of syscalls. 8)
Yes, I know.
A new ioctl on the socket should be able to do that
On Thu, Jan 18, 2001 at 11:37:10PM +0300, [EMAIL PROTECTED] wrote:
Hello!
Doing PUSH from setsockopt(TCP_CORK) looked obviously wrong because it isn't
setting any socket state,
? 8)
I thought setsockopt is meant to set an option in the socket, something
_stateful_, a PUSH doesn't set
On Thu, Jan 18, 2001 at 03:17:13PM -0200, Marcelo Tosatti wrote:
Jens, can be the -blk patch the reason for the slowdown I'm seeing?
This heuristic is way too aggressive:
/*
* Try to keep 128MB max hysteris. If not possible,
* use half of RAM
*/
On Thu, Jan 18, 2001 at 03:53:11PM -0800, Mike Kravetz wrote:
Here are some very preliminary numbers from sched_test_yield
(which was previously posted to this (lse-tech) list by Bill
Hartner). Tests were run on a system with 8 700 MHz Pentium
III processors.
On Thu, Jan 18, 2001 at 04:52:25PM -0800, Mike Kravetz wrote:
was less than the number of processors. I'll give the tests a try
with a smaller number of threads. I'm also open to suggestions for
OK!
what benchmarks/test methods I could use for scheduler testing. If
you remember what
On Thu, Jan 18, 2001 at 08:00:16PM -0500, Mark Hahn wrote:
microseconds/yield
# threads 2.2.16-22 2.42.4-multi-queue
- ---
16 18.7404.603 1.455
On Thu, Jan 18, 2001 at 09:44:57PM +0100, Ingo Molnar wrote:
why? TCP_CORK is equivalent to MSG_MORE, it's just a different
I thought you agreed it isn't (Linus's example I quoted).
Doing PUSH from setsockopt(TCP_CORK) looked obviously wrong because it
isn't setting any socket state, [...]
On Thu, Jan 18, 2001 at 10:57:20PM +0100, Ingo Molnar wrote:
On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
{
int val = 1;
setsockopt(req-sock, IPPROTO_TCP, TCP_CORK,
(char *)val,sizeof(val));
val = 0;
setsockopt(req-sock
On Thu, Jan 18, 2001 at 11:52:33AM -0800, Linus Torvalds wrote:
On Thu, 18 Jan 2001, Ingo Molnar wrote:
i believe a network-conscious application should use MSG_MORE - that has
no system-call overhead.
I think Andrea was thinking more of the case of the anonymous IO
generator, and
On Thu, Jan 18, 2001 at 08:43:47PM +0100, Ingo Molnar wrote:
On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
I'm all for TCP_CORK but it has the disavantage of two syscalls for
doing the flush of the outgoing queue to the network. And one of those
two syscalls is spurious. [...]
i
On Fri, Jan 19, 2001 at 11:58:03AM +0100, Rogier Wolff wrote:
Now if we design the NUMA support correctly, just filling in "disk has
a seek-time of 10ms, and 20Mb per second throughput when accessed
linearly" NUMA may on it's own "tune" the swapper to do the right
thing. And once parametrized
On Fri, Jan 19, 2001 at 08:52:53PM +0300, [EMAIL PROTECTED] wrote:
Hello!
I thought setsockopt is meant to set an option in the socket,
It is not.
The manpage disagrees with you:
getsockopt, setsockopt - get and set options on sockets
On Thu, Jan 18, 2001 at 11:18:48PM +0100, Ingo Molnar wrote:
On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
This is a possible slow (but userspace based) implementation of SIOCPUSH:
of course this is what i meant. Lets stop wasting time on this, ok?
We were both wrong. Not even my
On Fri, Jan 19, 2001 at 09:18:04PM +0300, [EMAIL PROTECTED] wrote:
Hello!
The "uncork" won't push the last skb on the wire if there is not acknowledged
data in the write_queue and the payload of the last skb in the write_queue
isn't large MSS. This because the `uncork' will only
On Sat, Jan 20, 2001 at 06:41:06PM +0100, [EMAIL PROTECTED] wrote:
hi,
got this oops when doing a
vgextend -v vgroot /dev/ide/host2/bus0/target0/lun0/part2 \
/dev/ide/host2/bus1/target0/lun0/part2
You should upgrade to 0.9.1_beta2 that should merge all the known fixes out
there. It's
On Sat, Jan 20, 2001 at 08:28:04PM +0300, [EMAIL PROTECTED] wrote:
Hello!
My argument applies to 2.4. The uncork _won't_ push on the wire the last
not mss-sized fragment until it's the last one in the write queue even once
cwnd and receiver window allows that. I think
Look at the
On Sat, Jan 20, 2001 at 10:05:45PM +0300, [EMAIL PROTECTED] wrote:
It makes. One small packet is allowed to fly, not depending on packets_out.
So this mean if I do:
write(10*MSS)
write(1)
write(1)
2.4 can send 10 packet with MSS large payload plus two packets
On Sat, Jan 20, 2001 at 11:22:14PM +0300, [EMAIL PROTECTED] wrote:
Hello!
write(10*MSS)
write(1)
write(1)
...
As far as I can tell, the second "write(1)" will always merge with the
first one
This would be true, if Andrea wrote not exactly 10*MSS,
but
On Sat, Jan 20, 2001 at 11:39:30AM -0800, Linus Torvalds wrote:
As far as I can tell, the second "write(1)" will always merge with the
first one - unless the first one has already been sent out, [..]
Here the question is only if the first write(1) will be still there when we do the
second
On Sat, Jan 20, 2001 at 10:39:36PM +0300, [EMAIL PROTECTED] wrote:
Much saner behaviour wrt latency (and perfect clarity) overweights
IMHO latency can be fixed in a much better way using ioctl(SIOCPUSH) after the
last write() plus we could also add a MSG_NOMORE to set in the last send().
On Wed, Jan 24, 2001 at 12:52:57AM +0100, Sasi Peter wrote:
On Sun, 14 Jan 2001, Godfrey Livingstone wrote:
You MUST apply this patch before the two raid patches. The VM patch stablises
the 2.2.18 virtual memory system and if you don't apply my two repackaged
patches will fail. The above
On Wed, Jan 24, 2001 at 01:43:26AM +0100, Sasi Peter wrote:
(30+ high speed streams from 4 disks does really need some caching).
This isn't obvious. Your working may not fit in cache and so the kernel
understand it's worthless to swapout stuff to make space to a polluted cache.
Can't say, of
On Tue, Jan 23, 2001 at 11:51:15PM -0800, Richard Henderson wrote:
On Thu, Jan 11, 2001 at 12:59:24AM +0100, Andrea Arcangeli wrote:
What I said is that I can write this C code:
int x[2], * p = (int *) (((char *) x)+1);
main()
{
*p = 0
On Wed, Jan 24, 2001 at 01:51:49AM -0800, Richard Henderson wrote:
On Wed, Jan 24, 2001 at 10:02:40AM +0100, Andrea Arcangeli wrote:
I'd love if you could forbid it to compile.
Problem is that there's stuff like this all over the place. Plus,
That's why I thought you were required to make
On Fri, Jan 26, 2001 at 12:05:56PM -0500, Simon Kirby wrote:
Hmm... Just wondering: what does TCP then do when it receives this ECN
notification? Try harder, try less? Or does it get a specific packet
It will act in the same way if it the packet was dropped (but the packet wasn't
dropped).
On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote:
On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote:
If that happens, and the socket uses GFP_ATOMIC allocation, the while (1)
loop in sock_alloc_send_skb() will endlessly spin, without ever calling
schedule(), and all the
On Thu, May 10, 2001 at 11:17:17PM +0200, Andi Kleen wrote:
On Thu, May 10, 2001 at 11:13:00PM +0200, Andrea Arcangeli wrote:
On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote:
On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote:
If that happens, and the socket uses
On Fri, May 11, 2001 at 03:32:46PM +0100, Alan Cox wrote:
Please fix the binary incompatibility in the on disk format between the current
code and your new release _before_ you do that. The last patches I was sent
would have screwed every 64bit LVM user.
I just switched to the =beta4 lvm IOP
Bootmem allocations are executed before all the reserved memory is been
reserved. This is the fix against 2.4.5pre1. This might explain weird
crashes and reserved twice error messages at boot on highmem systems.
I didn't yet had the confirm this patch hels but certainly it is a
necessary fix for
On Fri, May 11, 2001 at 05:18:35PM +0100, Alan Cox wrote:
reserved. This is the fix against 2.4.5pre1. This might explain weird
crashes and reserved twice error messages at boot on highmem systems.
Reserved twice occurs for two known reasons
BIOS reporting the same region twice or
On Sun, May 13, 2001 at 12:44:45AM +0900, root wrote:
On UP2000 SMP with two 21264 CPU's running 2.4.5pre1aa1 and 2.2.19aa1,
I am getting the following message:
===
May 12 07:02:09 norma kernel: TSUNAMI machine check: vector=0x630
On Fri, May 11, 2001 at 10:19:13PM -0700, David S. Miller wrote:
Andrea Arcangeli writes:
you _must_ know very well what the mainteinance of that code means ;).
Which is why I added the facility by which such ioctl conversions can
be registered at runtime by the subsystem/driver itself
On Fri, May 11, 2001 at 06:29:27PM -0700, David S. Miller wrote:
I think that's a bad decision, but it is your's.
Let me put it this way: after I get the first real life request from an
user with an useful case where a 32bit app needs to run the lvm ioctl it
will be truly easy to change my mind
This patch fixes the troubles generated by msync on /dev/fb0 or any
other device driver that exports reserved memory to userspace via shared
mapping.
--- 2.4.5pre1aa3/mm/filemap.c.~1~ Fri May 11 02:08:28 2001
+++ 2.4.5pre1aa3/mm/filemap.c Mon May 14 18:48:59 2001
@@ -1808,10 +1808,12 @@
Detailed description of 2.4.5pre2aa1 follows.
---
00_alpha-illegal-irq-1
Be verbose for MAX_ILLEGAL_IRQS times if an invalid irq number
is getting run.
(debugging)
00_alpha-ksyms-1
Export
The main features of 2.2.20pre2aa1 are:
o Support for 4Gigabyte of RAM on IA32 (me and Gerhard Wichert)
o Support for 2T of RAM on alpha (me)
o RAW-IO (doable with bigmem enabled too). Improvements are also been
backported from 2.4.
o SMP scheduler improvements.
On Wed, May 16, 2001 at 11:03:27AM +0200, [EMAIL PROTECTED] wrote:
David,
I am using the gcc-3.0 snapshot of 14.5.2001 from codesourcery (i686 binary).
I have now tried to mimic CPU=386 behaviour (patch posted yesterday night)
and it compiles (just sound fails), by exchanging y and n in
On Tue, May 15, 2001 at 08:42:03PM -0300, Rik van Riel wrote:
On Tue, 15 May 2001, Andrea Arcangeli wrote:
Detailed description of 2.4.5pre2aa1 follows.
00_buffer-2
Reschedule during oom while allocating buffers, still getblk
can deadlock with oom but this will hide
On Tue, May 15, 2001 at 08:33:05PM -0700, dean gaudet wrote:
On Tue, 15 May 2001, Andrea Arcangeli wrote:
o fixed race in wake-one LIFO in accept(2). Apache must be compiled with
-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT to take advantage of that.
00_wake-one-4
Backport 2.4
On Wed, May 16, 2001 at 02:52:04PM +0100, David Howells wrote:
Hi Andrea:
Here you go:
/usr/local/bin/gcc -D__KERNEL__ -I/inst-kernels/linux-2.4.5-pre2-aa/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686
On Wed, May 16, 2001 at 10:25:32AM -0700, dean gaudet wrote:
On Wed, 16 May 2001, Andrea Arcangeli wrote:
On Tue, May 15, 2001 at 08:33:05PM -0700, dean gaudet wrote:
apache since 1.3.15 has defined SINGLE_LISTEN_UNSERIALIZED_ACCEPT ...
That's definitely a good thing.
hmm, i'm
On Fri, May 18, 2001 at 09:46:17PM +0400, Ivan Kokshaysky wrote:
The most interesting thing here is the pyxis tbia fix.
Whee! I can now copy files from SCSI to bus-master IDE, or
between two IDE drives on separate channels, or do other nice
things without hanging lx/sx164. :-)
The pyxis tbia
On Sat, May 19, 2001 at 11:11:31PM +0400, Ivan Kokshaysky wrote:
On Sat, May 19, 2001 at 03:55:02PM +0200, Andrea Arcangeli wrote:
Reading the tsunami specs I learnt 1 tlb entry caches 8 pagetables (not 1)
so the tlb flush will be invalidate immediatly by any PCI DMA run after
the flush
On Sun, May 20, 2001 at 04:12:34PM +0400, Ivan Kokshaysky wrote:
On Sun, May 20, 2001 at 04:40:13AM +0200, Andrea Arcangeli wrote:
I was only talking about when you get the pci_map_sg failed because
you have not 3 but 300 scsi disks connected to your system and you are
writing to all them
[ cc'ed to l-k ]
DMA-mapping.txt assumes that it cannot fail.
DMA-mapping.txt is wrong. Both pci_map_sg and pci_map_single failed if
they returned zero. You either have to drop the skb or to try again later
if they returns zero.
Andrea
-
To unsubscribe from this list: send the line
On Mon, May 21, 2001 at 12:05:20AM +1000, Andrew Morton wrote:
Andrea Arcangeli wrote:
[ cc'ed to l-k ]
DMA-mapping.txt assumes that it cannot fail.
DMA-mapping.txt is wrong. Both pci_map_sg and pci_map_single failed if
they returned zero. You either have to drop the skb
On Sun, May 20, 2001 at 03:49:58PM +0200, Andrea Arcangeli wrote:
they returned zero. You either have to drop the skb or to try again later
if they returns zero.
BTW, pci_map_single is not a nice interface, it cannot return bus
address 0, so once we start the fixage it is probably better
On Mon, May 21, 2001 at 02:21:18AM +1000, Andrew Morton wrote:
Andrea Arcangeli wrote:
Would it not be sufficient to define a machine-specific
macro which queries it for error? On x86 it would be:
#define BUS_ADDR_IS_ERR(addr) ((addr) == 0)
that would be more flexible at least, however
On Mon, May 21, 2001 at 02:54:16AM +1000, Andrew Morton wrote:
No. Most of the pci_map_single() implementations just
use virt_to_bus()/virt_to_phys(). [..]
then you are saying that on the platforms without an iommu the pci_map_*
cannot fail, of course, furthmore even a missing pci_unmap
On Mon, May 21, 2001 at 01:59:25AM +0900, root wrote:
Andrea told us that he will not care for anything
compiled with gcc-2.95 or version lower than that.
I said I don't care about bugreport of alpha kernel crashes if the
_alpha_ kernel was compiled with gcc 2.95.*. 2.95 is fine on the x86,
On Sun, May 20, 2001 at 01:16:25PM -0400, Jeff Garzik wrote:
Andrea Arcangeli wrote:
On Sun, May 20, 2001 at 03:49:58PM +0200, Andrea Arcangeli wrote:
they returned zero. You either have to drop the skb or to try again later
if they returns zero.
BTW, pci_map_single is not a nice
On Sun, May 20, 2001 at 06:07:17PM -0700, David S. Miller wrote:
Andrea Arcangeli writes:
[..] Even sparc64's fancy
iommu-based pci_map_single() always succeeds.
Whatever sparc64 does to hide the driver bugs you can break it if you
pci_map 4G+1 bytes of phyical memory
On Sun, May 20, 2001 at 06:01:40PM -0700, David S. Miller wrote:
Andrea Arcangeli writes:
Well this is news to me. No drivers understand this.
Yes, almost all drivers are buggy.
No, the interface says that the DMA routines may not return failure.
The alpha returns a faliure
On Fri, May 11, 2001 at 01:12:55PM -0700, David S. Miller wrote:
They can be converted, [..]
of course, and part of that code will be still necessary also with the
=beta4 lvm interface to still convert the pointers of the userspace
data structures but my point was we probably want to avoid that
On Mon, May 21, 2001 at 03:59:58AM -0700, David S. Miller wrote:
This still leaves around 800MB IOMMU space free on that sparc64 PCI
controller.
if it was 400mbyte you were screwed up too, the point here is that the
marging is way too to allows ignore the issue completly, furthmore there
can
On Mon, May 21, 2001 at 10:53:39AM -0700, Richard Henderson wrote:
should probably just go ahead and allocate the 512M or 1G
scatter-gather arena.
I just have a bugreport in my mailbox about pci_map faliures even after
I enlarged to window to 1G argghh (at first it looked apparently stable
by
On Mon, May 21, 2001 at 10:53:39AM -0700, Richard Henderson wrote:
diff -ruNp linux/arch/alpha/kernel/pci_iommu.c
linux-new/arch/alpha/kernel/pci_iommu.c
--- linux/arch/alpha/kernel/pci_iommu.c Fri Mar 2 11:12:07 2001
+++ linux-new/arch/alpha/kernel/pci_iommu.c Mon May 21 01:25:25
On Tue, May 22, 2001 at 06:44:09PM +0400, Ivan Kokshaysky wrote:
On Tue, May 22, 2001 at 04:29:16PM +0200, Andrea Arcangeli wrote:
Ivan could you test the above fix on the platforms that needs the
align_entry hack?
That was one of the first things I noticed, and I've tried exactly
On Tue, May 22, 2001 at 10:04:39PM +0200, Andrea Arcangeli wrote:
diff -urN 2.4.5pre4/arch/alpha/kernel/pci_iommu.c
2.4.5pre5/arch/alpha/kernel/pci_iommu.c
--- 2.4.5pre4/arch/alpha/kernel/pci_iommu.c Sun Apr 1 01:17:07 2001
+++ 2.4.5pre5/arch/alpha/kernel/pci_iommu.c Tue May 22 22:04:07
On Thu, May 24, 2001 at 03:16:48AM +0900, G. Hugh Song wrote:
The following is the output from free
=
total used free sharedbuffers
cached
Mem: 10231281015640 7488
On Wed, May 23, 2001 at 01:01:56PM -0700, Linus Torvalds wrote:
[..] I assume that Andrea basically
made the block-size be the same as the page size. That's how I would have
exactly (softblocksize is 4k fixed, regardless of the page cache size to
avoid confusing device drivers).
done it (and
On Wed, May 23, 2001 at 06:13:13PM -0400, Alexander Viro wrote:
Uh-oh... After you solved what?
The superblock is pinned by the kernel in buffercache while you fsck a
ro mounted ext2, so I must somehow uptodate this superblock in the
buffercache before collecting away the pagecache containing
On Wed, May 23, 2001 at 04:40:14PM -0400, Jeff Garzik wrote:
Linus Torvalds wrote:
Now, it may be that the preliminary patches from Andrea do not work this
way. I didn't look at them too closely, and I assume that Andrea basically
made the block-size be the same as the page size. That's
On Wed, May 23, 2001 at 01:27:19PM +0100, David Howells wrote:
The bug in gcc 3.0 that stopped the inline asm constraints being interpreted
properly, and thus prevented linux from compiling is now fixed.
I'm writing this on top of 2.4.5pre5aa3 compiled with gcc-3_0-branch and
binutils cvs
On Thu, May 24, 2001 at 12:32:20AM +0200, Andrea Arcangeli wrote:
userspace. I will try to work on the blkdev patch tomorrow to bring it
in an usable state.
It seems in an usable state right but it is still very early beta, I
need to recheck the whole thing, I will do that tomorrow, for now
On Fri, May 25, 2001 at 10:12:51PM +0200, Andrea Arcangeli wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.4.5pre6/blkdev-pagecache-2
^ 4 sorry
-
To unsubscribe from this list: send the line
On Fri, May 25, 2001 at 05:25:03PM -0700, Jay Thorne wrote:
But Wu-ftpd is an easy to set up test bench, and is ubiquitous enough
that anyone with an alpha running SMP can test it. Note that this
My smp alpha box drives a single tulip over 12MB/sec in full duplex
using tcp without any problem
On Fri, May 25, 2001 at 10:01:37PM -0400, Ben LaHaise wrote:
On Sat, 26 May 2001, Andrea Arcangeli wrote:
On Fri, May 25, 2001 at 09:38:36PM -0400, Ben LaHaise wrote:
You're missing a few subtle points:
1. reservations are against a specific zone
A single zone is not used only
On Fri, May 25, 2001 at 09:38:36PM -0400, Ben LaHaise wrote:
You're missing a few subtle points:
1. reservations are against a specific zone
A single zone is not used only for one thing, period. In my previous
email I enlighted the only conditions under which a reserved pool can
avoid
On Fri, May 25, 2001 at 09:39:36PM -0400, Ben LaHaise wrote:
Sorry, this doesn't fix the problem. It still hangs on highmem machines.
Try running cerberus on a PAE kernel sometime.
There can be more bugs of course, two patches I posted are only meant to
fix deadlocks in the allocation fail
On Sat, May 26, 2001 at 12:26:38PM -0300, Rik van Riel wrote:
Guess what's in my patch?
that part is fine indeed, it's ages that I am telling that alloc_pages
must always be allowed to fail or things will deadlock, go back to the
discussion with Ingo of a few months ago, finally you seems
On Sat, May 26, 2001 at 08:23:00AM -0700, Linus Torvalds wrote:
On Sat, 26 May 2001, Andrea Arcangeli wrote:
I don't see where you fixed the deadlock in create_buffers, if you did
please show me which line of code is supposed to do that, I show you
below which lines of code in my
I merged Rik's three liner fix to alloc_pages for GFP_BUFFER, plus my
other fix in create_buffers wait_event and a bit bigger reserved pool of
async bh. I'd suggest to test if this makes the highmem deadlock to go
away.
Detailed description of 2.4.5aa1 follows.
1 - 100 of 3668 matches
Mail list logo
