Linux-Development-Sys Digest #683, Volume #8 Tue, 1 May 01 18:13:19 EDT
Contents:
Re: Promblems with initrd (Kasper Dupont)
Re: Linux, streams and the standard library (John Beardmore)
Re: Linux, streams and the standard library (John Beardmore)
Re: Software RAID-0 performance problem ... (Gilles Chanteperdrix)
Re: Win Modems ("LittleFish")
Fixed: DHCP client broken in 2.4.4 (Guy Geens)
Re: Software RAID-0 performance problem ... (William Gallafent)
Re: About jiffies in Kernel ("Peter T. Breuer")
Re: Promblems with initrd (Dimitri Maziuk)
Re: IO system throughput (Greg Copeland)
Re: IO system throughput (Greg Copeland)
Re: Is linux kernel preemptive?? (Greg Copeland)
need info on, how to use dma_handle.... ([EMAIL PROTECTED])
Re: mmap memory allocated with vmalloc ([EMAIL PROTECTED])
Re: Is linux kernel preemptive?? (Neal Tucker)
Networking in Linux (Chainsaws and Code)
----------------------------------------------------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Promblems with initrd
Date: Tue, 01 May 2001 09:07:09 +0000
Martin Haneman wrote:
>
> I want to build up my own Linux-Bootdisk. I have read that I can use the
> initrd for Filesystem in the Ramdisk. So I created a file and used
> mkfs.minix on it. After that I mounted it as loop device copied all needed
> files (mainly busybox). I have also created a dev directory with a file
> (created by makedev ) tty1. After that I build my own Kernel (2.2.19). Then
> I installed syslinux on the floppy. Copied all files which are needed
> (including the gziped minix image). The disk boots quite well until the
> Kernel is ready and the execution of linuxrc should start. The kernel tells
> me following: No inital console found .. No init found.. . After the the
> system stops. But initrd has been decompressed well into Ramdisk 0.
The message about no initial console means
that the file /dev/console is missing. You
can create that in the same way as tty1.
The message about no init found means that
the file /sbin/init is missing. There are
two different ways of using a ramdisk
during boot.
First of all you can use the ramdisk to do
some initialization before mounting the
real root device, in this case /linuxrc is
executed. When the real root device is
mounted /sbin/init is executed.
The other way is to simply use the ramdisk
as root device, in this case /linuxrc is
not used /sbin/init is executed on the
ramdisk.
If you only want to use the ramdisk and
not change to another root device later,
it is probably a good idea to make
/linuxrc a symbolic link to /sbin/init or
the other way around.
> 1.) What I have done wrong???
> 2.) What can be done better???
> 3.) In the Linux Router Project I have seen there is no filesystem image
> used for the root files they use a tgz file. How can I do that the kernel is
> always complaining about the Filesystem which is used in root.tgz??
>
> Thanks to all
>
> Martin Hanneman
Either there is a special patch on that
kernel to allow a .tgz file to be used as
root device or you have missed something
somewhere in the installation procedure.
--
Kasper Dupont
------------------------------
From: John Beardmore <[EMAIL PROTECTED]>
Subject: Re: Linux, streams and the standard library
Date: Tue, 1 May 2001 10:06:45 +0100
In message <[EMAIL PROTECTED]>, John Beardmore
<[EMAIL PROTECTED]> writes
>In message <[EMAIL PROTECTED]>, David Konerding
><[EMAIL PROTECTED]> writes
>
>>If you want standard C++ with the standard C++ library on Linux, and
>>you are using RH 6.2, then download gcc-2.95.3, compile and install it
>>according to the instructions,
>
>Thanks - that seems to have worked ! Now having a stupid problem with
>make not compiling all object files. Nothing to do with the compiler I
>guess though !
And as it turns out, nothing to do with make ! As usual 100% brain dead
user error !
Cheers, J/.
--
John Beardmore
------------------------------
From: John Beardmore <[EMAIL PROTECTED]>
Subject: Re: Linux, streams and the standard library
Date: Tue, 1 May 2001 10:09:30 +0100
In message <[EMAIL PROTECTED]>, David Konerding
<[EMAIL PROTECTED]> writes
>On Tue, 1 May 2001 00:39:21 +0100, John Beardmore
><[EMAIL PROTECTED]> wrote:
>>>If you want standard C++ with the standard C++ library on Linux, and
>>>you are using RH 6.2, then download gcc-2.95.3, compile and install it
>>>according to the instructions,
>>
>> Thanks - that seems to have worked ! Now having a stupid problem with
>> make not compiling all object files. Nothing to do with the compiler I
>> guess though !
>
>yeah, sorry, I can't help you with that-- make sure you use TABS not SPACES
>when indenting make.
Thanks ! That wasn't my problem as it happens, but I didn't know that
make took a view on that. I'd always assumed that any old white space
would do, and I tend to use spaces on most platforms so that the view of
the file doesn't keep altering with different interpretations of the
size of tab.
Cheers, J/.
--
John Beardmore
------------------------------
From: Gilles Chanteperdrix <[EMAIL PROTECTED]>
Subject: Re: Software RAID-0 performance problem ...
Date: 01 May 2001 13:58:48 +0400
William Gallafent <[EMAIL PROTECTED]> writes:
> (..)
> Slightly jumbled, but the conclusion is that if I run hdparm on both
> drives simultaneously, the transfer rate for each is halved ... even
> though they're on different IDE channels.
>
> So, what's the cause of the problem here? Is there something in the
> kernel driver for the piix ide chipset that's killing performance when
> accessing drives on different channels - or is it something with the new
>
> raidtools, or is it something with my configuration?
>
> All help welcome, and I'm happy to conduct experiments if this is
> necessary ...
Taken from the Ultra-DMA mini HOWTO:
The Intel TX chipset has a single FIFO for hard disk data shared by
its two IDE interfaces, so using 2 UDMA drives will not yield such a
great improvement over a single UDMA drive.
--
Gilles Chanteperdrix.
------------------------------
From: "LittleFish" <littlefish_au[SPAM ME AT YOUR OWN RISK]@yahoo.com>
Crossposted-To:
alt.computer.drivers,alt.os.linux,aus.computers.linux,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: Win Modems
Date: Tue, 1 May 2001 23:23:23 +1000
I have a Dynalink 56kFax voice data hardware modem ISA and it works O.K. I
had a Purertec 3911 before and it worked great.
littlefish
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> looking for a good, reliable modem that isnt winmodem based? try modems
> based on rockwell chipsets. rockwell isnt rockwell anymore its conexant
and
> i think they brought in a few changes, none too bad i think. i had a
> rockwell modem for years and it ran without problems at 56k, ermm.. until
i
> flashed it with the wrong firmware. but thats beyond the point, if youre
> looking for an alternative, try looking for old rockwells or the new
> conexants.
> hope this helps,
> the irish leprechaun
>
>
------------------------------
Subject: Fixed: DHCP client broken in 2.4.4
From: Guy Geens <[EMAIL PROTECTED]>
Date: Tue, 01 May 2001 13:42:45 GMT
I reverted the Realtek driver to the version from 2.4.3, and it works
now.
I'm going to file a bug report on this. (Although I think I'm not the
only one.)
--
G. ``Iggy'' Geens - ICQ: #64109250
Home: <[EMAIL PROTECTED]> - Work: <[EMAIL PROTECTED]>
WWW: http://users.pandora.be/guy.geens/
``I was thinking about how everyone was dying
and maybe it's time to live.'' - Eels
------------------------------
Date: Tue, 01 May 2001 15:01:41 +0100
From: William Gallafent <[EMAIL PROTECTED]>
Subject: Re: Software RAID-0 performance problem ...
Gilles Chanteperdrix wrote:
> Taken from the Ultra-DMA mini HOWTO:
>
> The Intel TX chipset has a single FIFO for hard disk data shared by
> its two IDE interfaces, so using 2 UDMA drives will not yield such a
> great improvement over a single UDMA drive.
Ah, interesting. I take it this is the same right through to the BX
chipset.
I can see how this will reduce the total throughput ... but does this
really mean that the PIIX4 chipset has a maximum total throughput of
~18MB/s? That seems a little low, particularly since the chip purports
to support UDMA33, so should be able to hit a total transfer rate of
33MB/s at least! Could it be that the overhead of swapping channels
kills the performance this much?
I noticed something on the kernel mailing list about this, but haven't
yet seen a solution. Also, some have reported no problems / good
transfer rates (>30MB/s) running RAID-0 on piix4.
Interestingly, the people with problems seem to have Abit BP6s, as I do.
Though it seems unlikely, it could in fact be a problem with this
specific motherboard, I suppose. (HPT366 on the BP6 is pretty bad, by
(almost) all accounts).
--
Bill Gallafent.
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: About jiffies in Kernel
Date: Tue, 01 May 2001 13:59:27 GMT
ouyang <[EMAIL PROTECTED]> wrote:
> I am a newbie in linux kernel programming.
> I am trying to get time measurement in kernel.
> Am I right to use jiffies? I am not sure about it.
Yes.
> If I am right, then what's the precision of jiffies?
one jiffie :-). It's equal to 1/HZ s.
> Thanks a lot.
No problem. You will find it easier using a book for initial referfence ..
Rubini's is excellent.
Peter
------------------------------
From: [EMAIL PROTECTED] (Dimitri Maziuk)
Subject: Re: Promblems with initrd
Date: 1 May 2001 17:20:11 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 01 May 2001 09:07:09 +0000, Kasper Dupont wrote:
> Martin Haneman wrote:
...
>> 3.) In the Linux Router Project I have seen there is no filesystem image
>> used for the root files they use a tgz file. How can I do that the kernel is
>> always complaining about the Filesystem which is used in root.tgz??
...
>
> Either there is a special patch on that
> kernel to allow a .tgz file to be used as
> root device or you have missed something
> somewhere in the installation procedure.
There is (was last time I looked) a kernel patch -- it unzips and untars
the .tgz to a ramdisk during bootup.
Dima
--
E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home)
http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key
We're sysadmins. Sanity happens to other people. -- Chris King in asr
------------------------------
Subject: Re: IO system throughput
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 01 May 2001 14:36:13 -0500
[EMAIL PROTECTED] writes:
[snip]
> What do you think of the following system call that exists under FreeBSD
> and allows to do the thing you like, if i don't err:
>
> int
> kqueue(void)
>
> int
> kevent(int kq, const struct kevent *changelist, int nchanges,
> struct kevent *eventlist, int nevents,
> const struct timespec *timeout)
>
> DESCRIPTION
> kqueue() provides a generic method of notifying the user when an event
> happens or a condition holds, based on the results of small pieces of
> kernel code termed filters. A kevent is identified by the (ident, fil-
> ter) pair; there may only be one unique kevent per kqueue.
>
> This is used to do asynchronous read or write:
>
> aio_read - asynchronous read from a file (REALTIME)
> aio_write - asynchronous write to a file (REALTIME)
>
>
Ya, I read an article about this a number of months back. I think it's pretty
cool. From that I've *read*, it is doing exactly what I've been talking about.
My memory is a little fuzzy on this, but I think a similar project is underway
for Linux. I don't remember if it was being built on the kqueue system or not.
Sorry. As for how well the above implementation works, I honestly don't know,
but from what I've read, they've done an excellent job.
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Subject: Re: IO system throughput
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 01 May 2001 14:37:16 -0500
Thanks,
I didn't know that!!!
Greg
[EMAIL PROTECTED] (Philip Armstrong) writes:
> sgi have written a patch which puts aio support along the lines of the
> freebsd implentation into the kernel. Whether it'll go into 2.5 or
> not, I don't know.
>
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Subject: Re: Is linux kernel preemptive??
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 01 May 2001 15:16:23 -0500
Kasper Dupont <[EMAIL PROTECTED]> writes:
> Greg Copeland wrote:
[snip]
> This is the point where you have misunderstood
> something. A system call cannot preempt another
> system call, no matter what the system looks like.
>
> When some code is running it keeps running until
> it gives up control or an interrupt arrives. If
And when an interrupt is processed, is it something
magical, or rather, an interrupt handler which is
pretty much a system call. Like I said, the mechanism
has no value in this conversation. Please tell me
why you'd think that there is something magical about
interrupts that makes them significantly distinct
from any other kernel function ("system call") other
than them being asynchronously triggered.
> code looses control because of an interrupt say
> that it was preempted. This is triggered by an
> interrupt, not a system call. It has to be this
Correct. Now, let's say there isn't an interrupt
handler for said interrupt. What happens? Ahhh,
it must be calling a function somewhere. In this
case, I'm calling it a "system call". Fact is, some
thing interrupted something else. The else, as it
pertains to my conversation is if it's a system
call (inside the kernel) or a user call (inside
the standard library). It really doesn't matter
that it's an interrupt causing the interruption
again, as it relates to this conversation.
> way because as long as our code is running the
> other system call is not running. If a system
> call runs with interrupts enabled it can be
> preempted otherwise it cannot, code that is not
> prepared to be preempted must run with interrupts
> disabled. If at some point another system call is
> started before the first one has completed it
> must be the case that the first one was preempted
> by an interrupt otherwise the second wouldn't
> even have had the chance to start.
That's correct. However, it doesn't validate or
invalidate anything that I've stated, however, it
does provide more detail. While I thank you for
offering the additional details, it doesn't have
anything to do with the topic at hand.
>
> Lots of system calls may sleep, that means
> explicitly giving up control by calling the
> scheduler. This is not called preemption, and is
> really a hole different topic.
That's correct. The thread of execution is yielding its
control and allowing something else to be scheduled. Having
said that, it does tie into what I've been saying, but you need
to look beyond the scheduler here. If a thread of execution
yielded within a "system call" (executing within a kernel
function), it may still have locks in place to preventing another
like-call from beginning, let alone completing to the point of yielding.
Thus, the _function_ may not be reentrant.
[lots snipped]
> > Please describe how you have have system call preemption
> > with coarse grain locks? In short, you can't because
> > the kernel will be locking out anyone else from attempting
> > to use the resource. It's hard to have one without the
> > other which is not what I *think* you seem to be implying.
>
> With the current design you cannot preempt a
> kernel process holding locks, it would lead to
> deadlocks. But that is really not that important,
> user space code can be preempted and we really
Needing and having are two different things. I think you
support my argument/statement.
> don't need more preemption than that. The reason
> we need fine grained locks is to better support
> SMP architectures. On an SMP Linux system a
> process will busy wait for spinlocks until the
> process on another CPU holding the lock releases
> it. If this happens too often we will waste lots
> of CPU cycles.
>
That's true, however, it also allows for lower maximum context
switch latencies, without regard for the number of CPUs in a
given system. In short, SMP is not the sole reason for fine
grain locking. Furthermore, some aspects of I/O related performance
can also be tied to this problem domain.
[lots more taken out here]
The conversation is continuing to be dragged from a macroscopic
level of detail to a microscopic thread because you seemingly
take issue with broad, high-level ("macroscopic") statements. From
what I can see, we are saying exactly the same thing, rather, you are
getting hung on the differences in syntax as being presented in a
macro-vs-micro conversation. If you want to continue this at a
microscopic scale, I'm happy to do so, however, this thread has taken
on a life well beyond it's original intent. The intent, at the time,
was to present the information at a macroscopic scale that a more
technical "laymen" could understand (notice the quotes, please use it
in proper context). This is why I insist that the mechanism (interrupt),
while provided more detail at the microscopic level, added no value
to the conversation; and so on.
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: need info on, how to use dma_handle....
Date: Tue, 01 May 2001 21:24:53 GMT
void * cpu_addr;
struct pci_dev *pci_dev;
dma_addr_t dma_handle;
int size=0xffff;
/* allocate dma region of size and return dma_handle & cpu_addr */
cpu_addr = pci_alloc_consistent(pci_dev, size, &dma_handle);
My question is, how do I use the dma_handle to access the allocated dma buffer
(from the PCI interface card ). When I installed this driver I got the following
values:
cpu_addr = 0xc7310000
dma_handle = 0x7310000
For example if I set the location pointed to by cpu_addr as:
*(unsigned int *)0xc7310000 = 1122;
Should, I be able to read it from the PCI card side, using the dma_handle. If it
is possible, how do I do it. Any help would be appreciated.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: mmap memory allocated with vmalloc
Date: Tue, 01 May 2001 21:30:32 GMT
Make sure the amount of memory you are trying to allocate is less than
(vma->vm_end - vma->vm_star).
In article <[EMAIL PROTECTED]>, Barry Smyth says...
>
>Hi,
>
>I am trying to map memory allocated in my driver to the user via mmap
>functionality. I am using vmalloc to allocate this memory as my memory
>requirements may exceed the 128K limit for kmalloc. Could someone please
>tell me why the following code does not work.
>
>
> unsigned long* kern_mem;
>
>In open function:
> kern_mem = (unsigned long*)vmalloc(PAGE_SIZE);
> mem_map_reserve(MAP_NR((unsigned long)kern_mem));
>
>In mmap function:
> remap_page_range(vma->vm_start,
> virt_to_phys((void*)kern_mem),
> PAGE_SIZE,
> vma->vm_page_prot);
>
>In release function:
> mem_map_unreserve(MAP_NR((unsigned long)kern_mem));
> vfree((void*)kern_mem);
>
>When accessing the memory from user space the memory seems to be filled
>with -1 values, even after changing the values from within the driver.
>When the memory allocation call is changed to kmalloc the code works
>fine.
>
>Thanks.
>
>Barry
------------------------------
From: [EMAIL PROTECTED] (Neal Tucker)
Subject: Re: Is linux kernel preemptive??
Date: 1 May 2001 14:41:40 -0700
Greg Copeland <[EMAIL PROTECTED]> wrote:
>Kasper Dupont <[EMAIL PROTECTED]> writes:
>
>> A system call cannot preempt another
>> system call, no matter what the system looks like.
>
>And when an interrupt is processed, is it something
>magical, or rather, an interrupt handler which is
>pretty much a system call.
I think if you guys start this conversation over after
agreeing on some definitions ("system call" seems like an
obvious one to work out, and conventionally does *not*
include interrupt handlers, I would guess), you'll find
that you agree on a lot more.
-Neal Tucker
------------------------------
Date: Tue, 1 May 2001 18:02:17 -0400
From: Chainsaws and Code <[EMAIL PROTECTED]>
Subject: Networking in Linux
Does anybody know where in the source the lowest level of handling network
packets occurs? This question is asked disreguarding drivers for NICs and
modems and such (as in the networking device has done its job, now what?)
If you have an idea (or even know for sure), I'd love to hear what ya have
to share!
~Dan
+======---
Dan Jarvis
e-mail: [EMAIL PROTECTED]
Internet: http://welcome.to/blufish
---======+
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
