Linux-Development-Sys Digest #702, Volume #8 Tue, 8 May 01 11:13:13 EDT
Contents:
Time to read the Disk (Chan Shing Hong)
Re: How to get a number of processors (Nix)
Re: user memory locked down to kernel pages? (Arne Driescher)
bind(), SO_REUSEADDR, and weird leftover states ([EMAIL PROTECTED])
Re: Little Help ([EMAIL PROTECTED])
Re: Time to read the Disk (Kasper Dupont)
Re: getting - "ioctl failed: Inappropriate ioctl for device" (Kasper Dupont)
Re: wait() and lost children (Kasper Dupont)
One-shot timer ("David Douglas")
Re: Time to read the Disk (Chan Shing Hong)
Re: One-shot timer (Kasper Dupont)
Re: Time to read the Disk (Kasper Dupont)
Re: Time to read the Disk (Marty)
kernel 2.4.2 floppy problem (jerome corre)
Re: Sun Solaris IPC (vardhan)
Re: STLport 4.0 & g++ 2.96 (Paul F. Kunz)
Re: wait() and lost children ([EMAIL PROTECTED])
Re: Time to read the Disk (Kasper Dupont)
kernel 2.4.2 floppy problem ([EMAIL PROTECTED])
Re: Time to read the Disk (Villy Kruse)
file read problem 2 (yan zhang)
Re: bind(), SO_REUSEADDR, and weird leftover states (Villy Kruse)
----------------------------------------------------------------------------
From: Chan Shing Hong <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Time to read the Disk
Date: Tue, 08 May 2001 18:12:05 +0800
I have bind a SCSI disk to a raw device at /dev/raw/raw1
When I try to read 128KB from the disk, I found that the time is about
the same as TWO reads where each read reads 64KB.
However, I think reading 128KB at a time should be faster than reading
64KB twice since it may save time on the rotation latency. Would anyone
tell me what's going on? Is the 128KB request broken up into two
requests???
Marty.
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: 08 May 2001 08:11:16 +0100
On Mon, 7 May 2001, John Beardmore said:
> In message <[EMAIL PROTECTED]>, Nix <$}xinix{[email protected]> writes
>
>><pedant>
>>No, you need to know the number of simultaneously executing tasks, which
>>is quite a different thing (or it could be, on high-end systems).
>
> Well what you really want to do is match the number of high priority threads to
>processors.
You are thinking inside a box (and having been in that box myself, I can
see how easy it is to get trapped inside).
You are *not* interested in how many physical processors exist. Why
should you be? You're interested in running a number of threads n at a
global maximum in the threads/performance space, such that if n is
increased, performance decreaases, and if n is decreased, performance
decreases.
Of course, the system can't find that global maximum for you (and it
changes from moment to moment as system load alters). But what it can do
is solve the simplest version, that you've been solving by saying `match
the number of threads to processors'. The graph of threads/performance
on an otherwise unloaded box peaks sharply where all threads are
simultaneously executing and none of them are contending for processing
time with each other --- but *why should a program author need to know
that*? The author should just be able to say `I can have been this many
and this many simultaneously executing threads of control. How many
should I have for maximum performance?'
And the system can answer, using *whatever information it has
available*, which may include average load from other processes, the
availability of distributed computational resources and who knows what
else.
>>The number of physical lumps of doped silicon inside the machine is an
>>irrelevant hardware detail.
>
> Nonsense.
I don't see why. You're operating at *least* one level of abstraction
too far down. Think what you're aiming for, `maximize
performace'. Unless your goal is `heat the room', you don't care how
many lumps of silicon do the computation, just that it proceeds as fast
as possible.
--
`I like to think the situation could be likened to doing heart surgery
in a hurry with a plastic spoon after having a couple of pints.'
--- James Reeves
------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Re: user memory locked down to kernel pages?
Date: Tue, 08 May 2001 13:15:52 +0200
Ralf Render wrote:
>
> Hi all,
>
> does anybody know, whether in one of the latest kernels it is possible
> to lock down user memory to kernel pages?
> My kernel driver needs to lock given user memory by preventing it form
> beeing swapped.
> I want to use the pages of this memory for a busmaster DMA of my
> PCI-Card to transfer data directly from PCI memory to user memory.
> After doing that the user memory should be unlocked.
> Thanks for help.
>
> Ralf.
You should rethink your approach. A driver should allocate
the memory by itself and provide it to the application via mmap.
This gives you painless access to the phys. addr. of the
pages and driver memory will never be swaped out.
-Arne
------------------------------
From: [EMAIL PROTECTED]
Subject: bind(), SO_REUSEADDR, and weird leftover states
Date: 8 May 2001 10:36:58 GMT
I've modified the gnu-pop3d server to set SO_REUSEADDR on the sockets
in daemon mode. Yet I am finding that when there are leftover
connection states after killing all the processes, I cannot get the
daemon to restart, until after all the leftover states clear out.
When the connections are leftover in TIME_WAIT, they generally go
away rather quickly. Others are not doing so. Sometimes I see
states like FIN_WAIT1, FIN_WAIT2, CLOSING, and LAST_ACK. And most
of the time they simply do not go away (have waited as long as 40
minutes before rebooting as the only means to clear it up).
This is only seen with gnu-pop3d, so something it is doing may be
weird, or maybe something that some mail client is doing (might be
an interesting DoS against Linux).
Kernel version is 2.2.14 and upgrading on this machine is not an
easy option, so it is best avoided unless certainly known to be the
issue for this problem (I'll have to wait a couple weeks before I
can do a speculative upgrade).
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Little Help
Date: 8 May 2001 10:39:34 GMT
On Tue, 08 May 2001 07:58:07 GMT Ryan <[EMAIL PROTECTED]> wrote:
| Hello, I have to do a uni assignment on how the Linux Kernel conducts either
| its
|
| - Processes,
| - Memory Management, or
| - File Systems,
|
| Maybe one of you gurus could reccomend which topic they think I should do,
| and suggest maybe a URL where I could find the appropriate resources...
| Only if you want to help that is!
What is the nature of the assignment? Write a report? Documentation?
Write code? What are you expected to hand in for whatever you choose?
BTW, all three of those things are interesting. WHy not read a little
bit first on all three, then decide what interests you more at that time.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Time to read the Disk
Date: Tue, 08 May 2001 11:45:01 +0000
Chan Shing Hong wrote:
>
> I have bind a SCSI disk to a raw device at /dev/raw/raw1
>
> When I try to read 128KB from the disk, I found that the time is about
> the same as TWO reads where each read reads 64KB.
>
> However, I think reading 128KB at a time should be faster than reading
> 64KB twice since it may save time on the rotation latency. Would anyone
> tell me what's going on? Is the 128KB request broken up into two
> requests???
>
> Marty.
I wouldn't expect the difference to be visible
with blocks as large as 64KB. If you try reading
data in 64 and 128 byte blocks you should see a
much larger difference. If the small requests
actually read sequential data you shouldn't be
able to see any rotation latence, at least not
if data are read in blocks of 1KB or more.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: getting - "ioctl failed: Inappropriate ioctl for device"
Date: Tue, 08 May 2001 11:47:30 +0000
[EMAIL PROTECTED] wrote:
>
> I am getting this message: 'ioctl failed: Inappropriate ioctl for device'
> Also, none of my fops are getting called including 'open'...when I look at my
> kernel driver log in /var/log/messages...what am I doing wrong here ..any info
>
> thanx,
> k
You have to describe your problem in more detail
if anybody should be able to help you. Do you
actually reference the f_ops structure in the
right place? Why not post some of your code?
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: wait() and lost children
Date: Tue, 08 May 2001 11:59:11 +0000
[EMAIL PROTECTED] wrote:
>
> I'm debugging a server program I did not write which has a loop
> which involves doing a wait(NULL) call if it has reached its
> maximum number of children. What seems to be happening is that
> if 2 or more children have exit status at the same time, the
> number of wakeups is less than the number of such children, and
> may even be as few as 1. This is on Linux 2.4. Is wait() allowed
> to behave this way?
I think not. The man page about wait() states that if wait
is called with the SA_NOCLDWAIT or if SIGCHLD is ignored,
wait() may wait for all children to terminate. But if the
number of times you can wait is more or less random it does
sound like a kernel bug. BTW do you see this problem on an
UP machine or a SMP machine?
--
Kasper Dupont
------------------------------
From: "David Douglas" <[EMAIL PROTECTED]>
Subject: One-shot timer
Date: Tue, 8 May 2001 21:57:45 +1000
Hi all,
I am looking so some example code of a one shot timer. I have an interrupt I
am handling but need to allow 5 to 6 msecs to pass by after the int before
trying something. I don't want to hang in a loop. I am using Redhat 6.2
(Zoot) and Kernel 2.2.14-12. Any help examples appreciated.
David
------------------------------
From: Chan Shing Hong <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Time to read the Disk
Date: Tue, 08 May 2001 20:25:11 +0800
I test it as follows:
Issues 20 block requests randomly where the blocksize is 131072 (128KB) and
the time taken is around 330ms.
Issues 20 block requests randomly where the blocksize is 65536(64KB) and the
time take is just around 175ms.
However, I expect the difference should not be so large since the data is
sequentially placed.
Marty.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: One-shot timer
Date: Tue, 08 May 2001 12:36:42 +0000
David Douglas wrote:
>
> Hi all,
>
> I am looking so some example code of a one shot timer. I have an interrupt I
> am handling but need to allow 5 to 6 msecs to pass by after the int before
> trying something. I don't want to hang in a loop. I am using Redhat 6.2
> (Zoot) and Kernel 2.2.14-12. Any help examples appreciated.
>
> David
The programable interval timer can be set in
one shot mode, but using it would require
large parts of the kernel to be reprogrammed.
Using the normal timer mechanisms will be a
lot easier, but will not allow that precise
timings unless the HZ value is set to at
least 1000. The default HZ value on i386 is
100 in which case you can sleep for 10-20
msecs.
Do you need code for kernel mode or user
mode?
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Time to read the Disk
Date: Tue, 08 May 2001 12:43:14 +0000
Chan Shing Hong wrote:
>
> I test it as follows:
>
> Issues 20 block requests randomly where the blocksize is 131072 (128KB) and
> the time taken is around 330ms.
> Issues 20 block requests randomly where the blocksize is 65536(64KB) and the
> time take is just around 175ms.
>
> However, I expect the difference should not be so large since the data is
> sequentially placed.
>
> Marty.
That just means that the data transfer rate is approx 8 MB/sec
and probably the seek time doesn't really affect your result.
What is the avareage seek time on your disk supposed to be?
--
Kasper Dupont
------------------------------
From: Marty <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Time to read the Disk
Date: Tue, 08 May 2001 21:40:22 +0800
The average seek time is around 4 - 5 ms.
The average rotational latency is 3ms.
Besides, those 20 block requests are seeking to different locations. For each
request, It will seek to a random position and read the disk at a size of
blocksize. The total time taken for 20 requests
for 64KB - 175ms
for 128KB - 330ms
I feel strange because much of the time should be spent on seeking and rotational
latency. Therefore, the difference in blocksize should be account for such large
difference.
Marty.
Kasper Dupont wrote:
> Chan Shing Hong wrote:
> >
> > I test it as follows:
> >
> > Issues 20 block requests randomly where the blocksize is 131072 (128KB) and
> > the time taken is around 330ms.
> > Issues 20 block requests randomly where the blocksize is 65536(64KB) and the
> > time take is just around 175ms.
> >
> > However, I expect the difference should not be so large since the data is
> > sequentially placed.
> >
> > Marty.
>
> That just means that the data transfer rate is approx 8 MB/sec
> and probably the seek time doesn't really affect your result.
> What is the avareage seek time on your disk supposed to be?
>
> --
> Kasper Dupont
------------------------------
From: jerome corre<[EMAIL PROTECTED]>
Subject: kernel 2.4.2 floppy problem
Date: Tue, 08 May 2001 14:05:23 GMT
hi,
I have just installed Red Hat 7.1 on an old PC,
However I cannot do enything with the floopy (mount, fsck, mk2fs...)
The floppy seems to work as I could access it normally when booting
with RedHat 6.2.
I don't really know what to do to fix the problem? any idea?
Here is the message i get when using
fsck.ext2 /dev/fd0
May 4 13:43:43 S003 kernel: floppy driver state
May 4 13:43:43 S003 kernel: -------------------
May 4 13:43:43 S003 kernel: now=656638 last interrupt=430 diff=656208 last
called handler=c0166c00
May 4 13:43:43 S003 kernel: timeout_message=redo fd request
May 4 13:43:43 S003 kernel: last output bytes:
May 4 13:43:43 S003 kernel: 0 0 0
May 4 13:43:43 S003 last message repeated 6 times
May 4 13:43:43 S003 kernel: 8 80 429
May 4 13:43:43 S003 last message repeated 3 times
May 4 13:43:43 S003 kernel: 8 80 430
May 4 13:43:43 S003 last message repeated 3 times
May 4 13:43:43 S003 kernel: e 80 430
May 4 13:43:43 S003 kernel: 8 80 430
May 4 13:43:43 S003 last message repeated 3 times
May 4 13:43:43 S003 kernel: last result at 430
May 4 13:43:43 S003 kernel: last redo_fd_request at 656338
May 4 13:43:43 S003 kernel:
May 4 13:43:43 S003 kernel: status=ff
May 4 13:43:43 S003 kernel: fdc_busy=1
May 4 13:43:43 S003 kernel: DEVICE_INTR=c0166c00
May 4 13:43:43 S003 kernel: cont=c025c398
May 4 13:43:43 S003 kernel: CURRENT=c10e8840
May 4 13:43:43 S003 kernel: command_status=-1
May 4 13:43:43 S003 kernel:
May 4 13:43:43 S003 kernel: floppy0: floppy timeout called
May 4 13:43:43 S003 kernel: end_request: I/O error, dev 02:00 (floppy), sector
0
Thanks for any help
Jerome
===========
Mr Jerome Corre
[EMAIL PROTECTED]
===========
Mr Jerome Corre
[EMAIL PROTECTED]
------------------------------
From: vardhan <[EMAIL PROTECTED]>
Crossposted-To:
comp.unix.questions,comp.unix.programmer,comp.os.linux.misc,comp.unix.solaris
Subject: Re: Sun Solaris IPC
Date: Tue, 08 May 2001 19:30:58 +0530
thanks all for you suggestions. I will go through the docs suggested!
--
Vardhan Walavalkar
email: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Paul F. Kunz)
Subject: Re: STLport 4.0 & g++ 2.96
Date: 08 May 2001 07:17:00 -0700
Steve Connet <[EMAIL PROTECTED]> writes:
> And like I said before, I heard it's almost next to impossible to
> revert back to an older version of gcc (ie. 2.95) on a RH7.0 system
> that has gcc 2.96 on it.
>
I've installed gcc 2.95.3 in /usr/local on my RH7.1 system and
compiled, linked, and ran my C++ programs with it without problems.
I use the STL that comes with gcc.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: wait() and lost children
Date: 8 May 2001 13:26:28 GMT
On Tue, 08 May 2001 11:59:11 +0000 Kasper Dupont <[EMAIL PROTECTED]> wrote:
| [EMAIL PROTECTED] wrote:
|>
|> I'm debugging a server program I did not write which has a loop
|> which involves doing a wait(NULL) call if it has reached its
|> maximum number of children. What seems to be happening is that
|> if 2 or more children have exit status at the same time, the
|> number of wakeups is less than the number of such children, and
|> may even be as few as 1. This is on Linux 2.4. Is wait() allowed
|> to behave this way?
|
| I think not. The man page about wait() states that if wait
| is called with the SA_NOCLDWAIT or if SIGCHLD is ignored,
| wait() may wait for all children to terminate. But if the
| number of times you can wait is more or less random it does
| sound like a kernel bug. BTW do you see this problem on an
| UP machine or a SMP machine?
UP.
SIGCHLD is being ignored.
What would you recommend to make sure that I get a wakeup exactly
once for each child (assuming, for example, I wanted to know the
status of each and every one), or else knew exactly how many did
exit, or how many are still running?
My first inclination is to keep a list of every forked child PID,
and after each wakeup, try to see which ones are still running.
But this would be a fair amount of work complicated by someone
else's program which doesn't follow the organization style I do
my thinking in.
The idea of the server is the simple case of discovering when a
child exits and then to start a new one to keep a certain number
of them running. I'm about to code up a server of my own which
will be doing things much like this, with many child processes
that can fairly frequently exit, so I'd like to pin this issue
down before I finish up that design so I make sure I've taken the
correct, or best, approach.
I don't see SA_NOCLDWAIT documented in the man pages. Looking in
the source for 2.4.2 I find these matches which seem to hint that
this isn't supported, yet:
arch/sparc64/solaris/signal.h:#define SOLARIS_SA_NOCLDWAIT 0x10000
include/asm-i386/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-i386/signal.h:#define SA_NOCLDWAIT 0x00000002 /* not supported yet */
include/asm-mips/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-mips/signal.h:#define SA_NOCLDWAIT 0x00010000 /* Not supported yet */
include/asm-alpha/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-alpha/signal.h:#define SA_NOCLDWAIT 0x00000020 /* not supported yet */
include/asm-m68k/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-m68k/signal.h:#define SA_NOCLDWAIT 0x00000002 /* not supported yet */
include/asm-sparc/signal.h:#define SA_NOCLDWAIT 0x100 /* not supported yet */
include/asm-ppc/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-ppc/signal.h:#define SA_NOCLDWAIT 0x00000002 /* not supported yet */
include/asm-sparc64/signal.h:#define SA_NOCLDWAIT 0x100 /* not supported yet */
include/asm-arm/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-arm/signal.h:#define SA_NOCLDWAIT 0x00000002 /* not supported yet */
include/asm-sh/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-sh/signal.h:#define SA_NOCLDWAIT 0x00000002 /* not supported yet */
include/asm-ia64/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-ia64/signal.h:#define SA_NOCLDWAIT 0x00000002 /* not supported yet */
include/asm-mips64/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-mips64/signal.h:#define SA_NOCLDWAIT 0x00010000 /* Not
supported yet */
include/asm-s390/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-s390/signal.h:#define SA_NOCLDWAIT 0x00000002 /* not supported yet */
include/asm-parisc/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-parisc/signal.h:#define SA_NOCLDWAIT 0x00000080 /* not supported
yet */
include/asm-cris/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-cris/signal.h:#define SA_NOCLDWAIT 0x00000002 /* not supported yet */
include/asm-s390x/signal.h: * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
include/asm-s390x/signal.h:#define SA_NOCLDWAIT 0x00000002 /* not supported yet */
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Time to read the Disk
Date: Tue, 08 May 2001 14:25:17 +0000
Marty wrote:
>
> The average seek time is around 4 - 5 ms.
> The average rotational latency is 3ms.
>
> Besides, those 20 block requests are seeking to different locations. For each
> request, It will seek to a random position and read the disk at a size of
> blocksize. The total time taken for 20 requests
> for 64KB - 175ms
> for 128KB - 330ms
>
> I feel strange because much of the time should be spent on seeking and rotational
> latency. Therefore, the difference in blocksize should be account for such large
> difference.
>
> Marty.
>
I suggest you make some more experiments.
Try increasing the number of requests by a
factor 100, that way you will get much more
precise measurements.
Also try more different block sizes from
4 KB to 256 KB. Try to see what happens if
you split your large 128 KB requests into
8 sequential 16 KB requests.
I also suggest you verify what throughput
you can get from sequential reads.
--
Kasper Dupont
------------------------------
From: [EMAIL PROTECTED]
Subject: kernel 2.4.2 floppy problem
Date: 8 May 2001 14:31:11 GMT
hi,
I have just installed Red Hat 7.1 on an old PC,
However I cannot do enything with the floopy (mount, fsck, mk2fs...)
The floppy seems to work as I could access it normally when booting
with RedHat 6.2.
I don't really know what to do to fix the problem? any idea?
Here is the message i get when using
fsck.ext2 /dev/fd0
May 4 13:43:43 S003 kernel: floppy driver state
May 4 13:43:43 S003 kernel: -------------------
May 4 13:43:43 S003 kernel: now=656638 last interrupt=430 diff=656208 last
called handler=c0166c00
May 4 13:43:43 S003 kernel: timeout_message=redo fd request
May 4 13:43:43 S003 kernel: last output bytes:
May 4 13:43:43 S003 kernel: 0 0 0
May 4 13:43:43 S003 last message repeated 6 times
May 4 13:43:43 S003 kernel: 8 80 429
May 4 13:43:43 S003 last message repeated 3 times
May 4 13:43:43 S003 kernel: 8 80 430
May 4 13:43:43 S003 last message repeated 3 times
May 4 13:43:43 S003 kernel: e 80 430
May 4 13:43:43 S003 kernel: 8 80 430
May 4 13:43:43 S003 last message repeated 3 times
May 4 13:43:43 S003 kernel: last result at 430
May 4 13:43:43 S003 kernel: last redo_fd_request at 656338
May 4 13:43:43 S003 kernel:
May 4 13:43:43 S003 kernel: status=ff
May 4 13:43:43 S003 kernel: fdc_busy=1
May 4 13:43:43 S003 kernel: DEVICE_INTR=c0166c00
May 4 13:43:43 S003 kernel: cont=c025c398
May 4 13:43:43 S003 kernel: CURRENT=c10e8840
May 4 13:43:43 S003 kernel: command_status=-1
May 4 13:43:43 S003 kernel:
May 4 13:43:43 S003 kernel: floppy0: floppy timeout called
May 4 13:43:43 S003 kernel: end_request: I/O error, dev 02:00 (floppy),
sector
0
Thanks for any help
Jerome
===========
Mr Jerome Corre
[EMAIL PROTECTED]
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Time to read the Disk
Date: 8 May 2001 14:52:27 GMT
On Tue, 08 May 2001 20:25:11 +0800,
Chan Shing Hong <[EMAIL PROTECTED]> wrote:
>I test it as follows:
>
>Issues 20 block requests randomly where the blocksize is 131072 (128KB) and
>the time taken is around 330ms.
>Issues 20 block requests randomly where the blocksize is 65536(64KB) and the
>time take is just around 175ms.
>
>However, I expect the difference should not be so large since the data is
>sequentially placed.
>
The disk driver software and/or the controller hardware may combine
multiple read requests into one, as long as the requests are for consequtive
disk blocks. Before the disk driver sees your request it is broken up into
page size blocks, so the contigous disk access is what realy matters here.
Villy
------------------------------
From: yan zhang <[EMAIL PROTECTED]>
Subject: file read problem 2
Date: Tue, 08 May 2001 09:52:37 -0500
This is a part of my .c program. There's no complain with filp_open,
srcf->f_op, srcf->f_op->read, but srcf->f_op->read
After I "Before file open..\n", system is crashed with these message:
kernel panic : Aiee, killing interrupt handler
In interrupt handler - not syncing
The file I tried to read is a simple text file with a bunch of usual
characters.
buffer=(unsigned char *) page;
srcf=filp_open("/home/lws/groper/indexhtml", O_RDONLY, 0); // NO
COMPLAIN
if(IS_ERR(srcf)){printk("Error opening indexhtml!\n");
busywait(WAIT*5); return NULL;}//NO COMPLAIN
else
{
printk("File is opened...\n"); busywait(WAIT*5);
if(srcf->f_op && srcf->f_op->read)// NO COMPLAIN
{
printk("Structure file successfully!\n");
busywait(WAIT*5);
do
{
printk("Before file open...\n");
busywait(WAIT*5);
retval=srcf->f_op->read(srcf, buffer, PAGE_SIZE, &srcf->f_pos);
//SYSTEM CRASH
printk("After file open...\n");
busywait(WAIT*5);
if(retval<0){printk("Reading file failed!\n");
busywait(WAIT*5); return NULL;}
if(retval>0)
{
//result=buffer;
if(buffer == NULL){printk("Buffer is NULL\n"); return NULL;}
else {printk("Printing the file data...\n"); busywait(WAIT*5);}
}
}while(retval>0);
}
free_page(page);
}
retval=filp_close(srcf,NULL);
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: bind(), SO_REUSEADDR, and weird leftover states
Date: 8 May 2001 14:55:35 GMT
On 8 May 2001 10:36:58 GMT,
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>I've modified the gnu-pop3d server to set SO_REUSEADDR on the sockets
>in daemon mode. Yet I am finding that when there are leftover
>connection states after killing all the processes, I cannot get the
>daemon to restart, until after all the leftover states clear out.
>
You do that on the listen socket before binding the address and port number
to that socket?
Villy
------------------------------
** 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
******************************
