This is not a real patch but it works fine for me:
--- drivers/char/serial.c.orig Thu May 3 09:29:00 2001
+++ drivers/char/serial.c Thu May 3 09:29:34 2001
@@ -1764,8 +1764,8 @@
/*
* !!! ignore all characters if CREAD is not set
*/
- if ((cflag & CREAD)
This is not a real patch but it works fine for me:
--- drivers/char/serial.c.orig Thu May 3 09:29:00 2001
+++ drivers/char/serial.c Thu May 3 09:29:34 2001
@@ -1764,8 +1764,8 @@
/*
* !!! ignore all characters if CREAD is not set
*/
- if ((cflag CREAD) ==
Jeff Garzik schrieb:
>
> Martin Dalecki wrote:
> > > - I force the virtual blocksize for all the blkdev I/O
> > > (buffered and direct) to work with a 4096 bytes granularity instead of
> >
> > You mean PAGE_SIZE :-).
Or maybe 8192 bytes on alphas ?!? ;-)
-
To unsubscribe from this list: send
> considered to be in the "window of scarcity" (today we have 100MBit
> Ethernets and 133++MB/s PCI). Tomorrow our operating system concepts
> have to cope with 1, 10, ?? Gigabit Ethernets, Infiniband ,
> ... who knows.
We had to write our own RPC mechanism because with the standard-stacks
we
considered to be in the window of scarcity (today we have 100MBit
Ethernets and 133++MB/s PCI). Tomorrow our operating system concepts
have to cope with 1, 10, ?? Gigabit Ethernets, Infiniband ,
... who knows.
We had to write our own RPC mechanism because with the standard-stacks
we had no
Jeff Garzik schrieb:
Martin Dalecki wrote:
- I force the virtual blocksize for all the blkdev I/O
(buffered and direct) to work with a 4096 bytes granularity instead of
You mean PAGE_SIZE :-).
Or maybe 8192 bytes on alphas ?!? ;-)
-
To unsubscribe from this list: send the line
Hi,
Here's a small patch which defines rwlock_init() for alphas. It's
defined for all the other platforms.
Reto
--- include/asm-alpha/spinlock.h.orig Thu May 3 11:00:08 2001
+++ include/asm-alpha/spinlock.hThu May 3 11:01:46 2001
@@ -95,6 +95,7 @@
}
Hi,
Here's a small patch which defines rwlock_init() for alphas. It's
defined for all the other platforms.
Reto
--- include/asm-alpha/spinlock.h.orig Thu May 3 11:00:08 2001
+++ include/asm-alpha/spinlock.hThu May 3 11:01:46 2001
@@ -95,6 +95,7 @@
}
Hi
I just installed 2.4.4 on our alpha SMP boxes (ES40) and now I have
problems with the serial console:
sulogin does not accept input from the serial line
mingetty does not accept input from the serial line
agetty works fine
Everything works fine for the 2.4.2 kernel. I took the .config file
Hi
I just installed 2.4.4 on our alpha SMP boxes (ES40) and now I have
problems with the serial console:
sulogin does not accept input from the serial line
mingetty does not accept input from the serial line
agetty works fine
Everything works fine for the 2.4.2 kernel. I took the .config file
Ingo Molnar wrote:
> question: what is this application, and why does it need so much virtual
> memory? vmalloc()-able memory is maximized to 128 MB right now, and
> increasing it conflicts with directly mapping RAM, so generally it's a
> good idea to avoid vmalloc() as much as possible.
We
Ingo Molnar wrote:
question: what is this application, and why does it need so much virtual
memory? vmalloc()-able memory is maximized to 128 MB right now, and
increasing it conflicts with directly mapping RAM, so generally it's a
good idea to avoid vmalloc() as much as possible.
We
>
>
>
> On Fri, 8 Dec 2000, Alan Cox wrote:
>
> > > Yes, and I believe that this is what's broken about the SCSI midlayer. The the
> > > io_request_lock cannot be completely released in a SCSI HBA because the flags
> >
> > You can drop it with spin_unlock_irq and that is fine. I do that with
On Fri, 8 Dec 2000, Alan Cox wrote:
Yes, and I believe that this is what's broken about the SCSI midlayer. The the
io_request_lock cannot be completely released in a SCSI HBA because the flags
You can drop it with spin_unlock_irq and that is fine. I do that with no
problems
>
> > I looked at the implementation of the nbd which just calls
> >
> > spin_unlock_irq(_request_lock);
> > ... do network io ...
> > spin_lock_irq(_request_lock);
> >
> > This seems to work but it looks very dangerous to me (and ugly, too). Isn't there
>a better way to do this?
Hi
I'm trying to write a block device driver which does some network stuff to satisfy the
requests. The problem is, that the network stuff wants to grab the io_request_lock
which does not work because this lock is already locked when I come into the
request_fn of my device.
I looked at the
Hi
I'm trying to write a block device driver which does some network stuff to satisfy the
requests. The problem is, that the network stuff wants to grab the io_request_lock
which does not work because this lock is already locked when I come into the
request_fn of my device.
I looked at the
I looked at the implementation of the nbd which just calls
spin_unlock_irq(io_request_lock);
... do network io ...
spin_lock_irq(io_request_lock);
This seems to work but it looks very dangerous to me (and ugly, too). Isn't there
a better way to do this?
It is
Hi
Imagine we have a virtual disk which provides a 64bit (sparse) address
room. Unfortunately we can not use it as a block device because in a lot
of places (including buffer_head structure), we're using a long or even
an int for the block number.
Is there any way of getting a standardized way
Hi
Imagine we have a virtual disk which provides a 64bit (sparse) address
room. Unfortunately we can not use it as a block device because in a lot
of places (including buffer_head structure), we're using a long or even
an int for the block number.
Is there any way of getting a standardized way
Hi!
It's great that you could fix that!
Is there any chance that we will see this patch as well as your other
Alpha patches included in future 2.2.X and 2.4.X releases?
Thanks,
Reto
Andrea Arcangeli wrote:
>
> There were a few SMP races that could trigger only using threads:
>
> 1)
Hi!
It's great that you could fix that!
Is there any chance that we will see this patch as well as your other
Alpha patches included in future 2.2.X and 2.4.X releases?
Thanks,
Reto
Andrea Arcangeli wrote:
There were a few SMP races that could trigger only using threads:
1)
Hi
I think I have a possible explanation for your observations:
1) 1024B Block size:
> User time (seconds): 69.32
> System time (seconds): 25.15
> Percent of CPU this job got: 54%
> Elapsed (wall clock) time (h:mm:ss or m:ss): 2:54.14
> Major (requiring
Hi
I think I have a possible explanation for your observations:
1) 1024B Block size:
User time (seconds): 69.32
System time (seconds): 25.15
Percent of CPU this job got: 54%
Elapsed (wall clock) time (h:mm:ss or m:ss): 2:54.14
Major (requiring I/O)
lock_kernel is a special case and will not block when you call it in
order to create a new kernel thread. Look at the implementation of
lock_kernel if you have any doubts (this is true for the 2.2 kernels. I
don't know it by heart for the 2.4 kernel).
Reto
"M.Kiran Babu" wrote:
>
>
When you add it to the task switcher, it takes away a lot of cpu cycles
during each task switch and slows down your system. I think this was the
main idea behind _not_ saving those registers. IMHO, it does not make
sense to generally save these registers when nobody else but your driver
uses
When you add it to the task switcher, it takes away a lot of cpu cycles
during each task switch and slows down your system. I think this was the
main idea behind _not_ saving those registers. IMHO, it does not make
sense to generally save these registers when nobody else but your driver
uses
Update: I just tested it on Alpha UP and everything's fine. It really
seems to be a SMP problem...
Reto Baettig wrote:
>
> Hi
>
> I have a problem whith Alpha SMP's which seems to be kernel-related. I
> discussed this on the bug-glibc list but everybody seems to agree t
Hi
I have a problem whith Alpha SMP's which seems to be kernel-related. I
discussed this on the bug-glibc list but everybody seems to agree that
it cannot be a libc problem.
I attached a little testprogram which reproduces the bug in < 1Minute.
BUT: IT MUST BE STARTED AT LEAST TWICE!
The
Hi
I have a problem whith Alpha SMP's which seems to be kernel-related. I
discussed this on the bug-glibc list but everybody seems to agree that
it cannot be a libc problem.
I attached a little testprogram which reproduces the bug in 1Minute.
BUT: IT MUST BE STARTED AT LEAST TWICE!
The
Update: I just tested it on Alpha UP and everything's fine. It really
seems to be a SMP problem...
Reto Baettig wrote:
Hi
I have a problem whith Alpha SMP's which seems to be kernel-related. I
discussed this on the bug-glibc list but everybody seems to agree that
it cannot be a libc
stuff with the network?
Sorry for the newbie questions, but it's really hard to find information
about Tux (other than the holy source code, of course ;-)
TIA
Reto
Rik van Riel wrote:
>
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> > Rik van Riel wrote:
> > > On Tue, 31 O
Rik van Riel wrote:
> Ummm, last I looked Linux held the Specweb99 record;
> by a wide margin...
...does that remove any memory copies???
To be best does not mean that there's no place for improvment.
Can anybody please help me and tell me where to start understanding what
tux does?
Alan Cox wrote:
>
> > Why not solve the problem at the source and completely redesign the
> > network stack? Get rid of the old sk_buff & co! Rip the whole network
> > layer out! Redesign it and give the user a possibility of Zero-Copy
> > networking!
>
> For one because you don't need to do
When I'm following this thread, you guys seem to forget the _basics_:
The Linux networking stack sucks!
Everybody tries to work around the networking stack. We just recently
developped a rpc protocol which makes 180MBytes/second (over a Quadrics
Network) because the linux network layer was way
When I'm following this thread, you guys seem to forget the _basics_:
The Linux networking stack sucks!
Everybody tries to work around the networking stack. We just recently
developped a rpc protocol which makes 180MBytes/second (over a Quadrics
Network) because the linux network layer was way
Alan Cox wrote:
Why not solve the problem at the source and completely redesign the
network stack? Get rid of the old sk_buff co! Rip the whole network
layer out! Redesign it and give the user a possibility of Zero-Copy
networking!
For one because you don't need to do that to get
Rik van Riel wrote:
Ummm, last I looked Linux held the Specweb99 record;
by a wide margin...
...does that remove any memory copies???
To be best does not mean that there's no place for improvment.
Can anybody please help me and tell me where to start understanding what
tux does?
www.tux.org
stuff with the network?
Sorry for the newbie questions, but it's really hard to find information
about Tux (other than the holy source code, of course ;-)
TIA
Reto
Rik van Riel wrote:
On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
Rik van Riel wrote:
On Tue, 31 Oct 2000, Reto Baettig wrote
39 matches
Mail list logo
