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 t
> 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
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 @@
} /*__attribute__((aligned(32)
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 f
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 imple
Hi
We have an application that makes extensive use of vmalloc (we need
lots of large virtual contiguous buffers. The buffers don't have to be
physically contiguous).
vmalloc/vfree is very slow when the vmlist gets long.
I don't know if this problem is already on a todo list or if we are the
fir
>
>
>
> 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
>
> > 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
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 im
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) flush_t
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/
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:
>
> si
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 them.
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 ag
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 stran
-copy 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
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.or
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 tha
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 to
21 matches
Mail list logo
