Linux-Development-Sys Digest #696, Volume #8 Mon, 7 May 01 05:13:10 EDT
Contents:
Re: How to get a number of processors (Dave Blake)
Re: How to get a number of processors (Chris)
Re: programming the serial port (Carlos Justiniano)
RAID problems ("Brad Hubbard")
Unable to compile 2.4.4 - rwsem error (gf)
Re: cache coherency, threads, SMP (Rik van Riel)
Re: disk request ordering dependency ([EMAIL PROTECTED])
Re: accessing memory and IO space (Arne Driescher)
Re: disk request ordering dependency (Alexander Viro)
Re: programming the serial port (Moritz Franosch)
Re: losing bottom halves ("Barry Smyth")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dave Blake)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: 6 May 2001 23:46:25 GMT
Reply-To: [EMAIL PROTECTED]
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> On 04 May 2001 14:59:29 -0500, Greg Copeland <[EMAIL PROTECTED]> wrote:
> >
> >Oddly enough, my man page for sysconf doesn't show the _SC_NPROCESSORS_CONF
> >option. Hmm....wonder how long it's been around. Does it exist for Linux?
>
> I *think* this is new in glibc2.2. If you don't have this sysconf, you can do
> the C equivalent of:
>
> grep processor < /proc/cpuinfo | wc -l
It is actually recommended to use /proc/stat instead. This
came up when procps didn't work properly for SMP machines.
These sections of the /proc filesystem are considered malleable
- but /proc/stat is considered more stable than /proc/cpuinfo.
FWIW.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: Chris <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Date: Mon, 07 May 2001 00:12:26 +0000
Kaz Kylheku wrote:
>
> On 04 May 2001 14:59:29 -0500, Greg Copeland <[EMAIL PROTECTED]> wrote:
> >
> >Oddly enough, my man page for sysconf doesn't show the _SC_NPROCESSORS_CONF
> >option. Hmm....wonder how long it's been around. Does it exist for Linux?
>
> I *think* this is new in glibc2.2. If you don't have this sysconf, you can do
Nope... it's present in 2.0.7, certainly.
--
Chris Lightfoot -- chris at ex dash parrot dot com -- www.ex-parrot.com/~chris/
Never criticise somebody until you have walked a mile in their shoes.
That way, they're a mile away, and you have their shoes.
------------------------------
From: [EMAIL PROTECTED] (Carlos Justiniano)
Subject: Re: programming the serial port
Date: Mon, 07 May 2001 01:39:35 GMT
Javier,
If you haven't already come across the "Serial Programming Guide for
POSIX Operating Systems", I highly recommend it!
http://www.easysw.com/~mike/serial/serial.html
- Carlos
>
> hello!
>
> I'm coding some stuff with datagrams and my serial port
>(related to some telephony devices). Everything works, but I'd like to
>improve the feautures for the serial port, like timeout, carrier
>detect, and maybe, autodetection of some parameters.
>
> I believe that there are some sites or some mailing list
>related for this issue... or even, a good reference book for all
>this...
>
> any suggestion?
>
> thanks in advance
>
>--
>signed,
> Javier Loureiro Varela
> Class One
> System Research Leader
------------------------------
Reply-To: "Brad Hubbard" <[EMAIL PROTECTED]>
From: "Brad Hubbard" <[EMAIL PROTECTED]>
Subject: RAID problems
Date: Mon, 07 May 2001 02:24:52 GMT
Anyone know what this means, or where to start looking for an answer?
I've set up my first server running RH 7.1 Kernel 2.4.2-2 and am getting
some weird RAID
messages in /var/log/messages and dmesg output.
They are as follows;
created md2
bind<hda6,1>
bind<hdc6,2>
running: <hdc6><hda6>
hdc6's event counter: 00000012
hda6's event counter: 00000012
RAID level 1 does not need chunksize! Continuing anyway.
request_module[md-personality-3]: Root fs not mounted
md.c: personality 3 is not loaded!
do_md_run() returned -22
md2 stopped.
unbind<hdc6,1>
export_rdev(hdc6)
unbind<hda6,0>
export_rdev(hda6)
Any ideas?
Brad Hubbard
Congo Systems
12 Northgate Drive,
Thomastown, Victoria, Australia 3074
Email: [EMAIL PROTECTED]
Ph: +61-3-94645981
Fax: +61-3-94645982
Mob: +61-419107559
--
Brad Hubbard
Congo Systems
12 Northgate Drive,
Thomastown, Victoria, Australia 3074
Email: [EMAIL PROTECTED]
Ph: +61-3-94645981
Fax: +61-3-94645982
Mob: +61-419107559
------------------------------
From: gf <[EMAIL PROTECTED]>
Subject: Unable to compile 2.4.4 - rwsem error
Date: Mon, 07 May 2001 04:40:50 GMT
Perhaps this is a known problem.
I patched 2.4.3 to 2.4.4 with the following commands:
cd /usr/src
cp -r linux-2.4.3 linux-2.4.4
ln -s linux-2.4.4 linux
cd linux
mv ../patch-2.4.4 .
patch -p1 < patch-2.4.4
When I compiled bzImage (using old .config from 2.4.3) I got the following
errors:
arch/i386/kernel/kernel.o(.text.lock+0x20): undefined reference to
`rwsem_down_write_failed'
arch/i386/kernel/kernel.o(.text.lock+0x34): undefined reference to
`rwsem_wake'
arch/i386/kernel/kernel.o(.text.lock+0x40): undefined reference to
`rwsem_down_write_failed'
arch/i386/kernel/kernel.o(.text.lock+0x54): undefined reference to
`rwsem_wake'
arch/i386/kernel/kernel.o(.text.lock+0x60): undefined reference to
`rwsem_down_write_failed'
arch/i386/kernel/kernel.o(.text.lock+0x74): undefined reference to
`rwsem_wake'
arch/i386/kernel/kernel.o(.text.lock+0x81): undefined reference to
`rwsem_down_read_failed'
arch/i386/kernel/kernel.o(.text.lock+0x96): undefined reference to
`rwsem_wake'
arch/i386/kernel/kernel.o(.text.lock+0xa3): undefined reference to
`rwsem_down_read_failed'
arch/i386/kernel/kernel.o(.text.lock+0xb8): undefined reference to
`rwsem_wake'
arch/i386/mm/mm.o(.text.lock+0x3): undefined reference to
`rwsem_down_read_failed'
arch/i386/mm/mm.o(.text.lock+0x18): undefined reference to `rwsem_wake'
arch/i386/mm/mm.o(.text.lock+0x2c): undefined reference to `rwsem_wake'
arch/i386/mm/mm.o(.text.lock+0x40): undefined reference to `rwsem_wake'
arch/i386/mm/mm.o(.text.lock+0x54): undefined reference to `rwsem_wake'
kernel/kernel.o(.text.lock+0xc): undefined reference to
`rwsem_down_write_failed'
kernel/kernel.o(.text.lock+0x20): undefined reference to `rwsem_wake'
kernel/kernel.o(.text.lock+0x41): undefined reference to
`rwsem_down_read_failed'
kernel/kernel.o(.text.lock+0x56): undefined reference to `rwsem_wake'
kernel/kernel.o(.text.lock+0x62): undefined reference to
`rwsem_down_write_failed'
kernel/kernel.o(.text.lock+0x76): undefined reference to `rwsem_wake'
kernel/kernel.o(.text.lock+0x83): undefined reference to
`rwsem_down_read_failed'
kernel/kernel.o(.text.lock+0x98): undefined reference to `rwsem_wake'
kernel/kernel.o(.text.lock+0xa5): undefined reference to
`rwsem_down_read_failed'
kernel/kernel.o(.text.lock+0xba): undefined reference to `rwsem_wake'
kernel/kernel.o(.text.lock+0xc7): undefined reference to
`rwsem_down_read_failed'
kernel/kernel.o(.text.lock+0xdc): undefined reference to `rwsem_wake'
kernel/kernel.o(.text.lock+0xe8): undefined reference to
`rwsem_down_write_failed'
kernel/kernel.o(.text.lock+0xfc): undefined reference to `rwsem_wake'
kernel/kernel.o(.text.lock+0x109): undefined reference to
`rwsem_down_read_failed'
kernel/kernel.o(.text.lock+0x11e): undefined reference to `rwsem_wake'
kernel/kernel.o(.text.lock+0x12a): undefined reference to
`rwsem_down_write_failed'
kernel/kernel.o(.text.lock+0x13e): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x2): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0x16): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x2a): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x36): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0x4a): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x56): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0x6a): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x8b): undefined reference to
`rwsem_down_read_failed'
mm/mm.o(.text.lock+0xa0): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0xac): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0xc0): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0xcd): undefined reference to
`rwsem_down_read_failed'
mm/mm.o(.text.lock+0xe2): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x102): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0x116): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x122): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0x136): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x142): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0x156): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x162): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0x176): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x182): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0x196): undefined reference to `rwsem_wake'
mm/mm.o(.text.lock+0x1a2): undefined reference to
`rwsem_down_write_failed'
mm/mm.o(.text.lock+0x1b6): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x98): undefined reference to
`rwsem_down_write_failed'
fs/fs.o(.text.lock+0xac): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x176): undefined reference to
`rwsem_down_write_failed'
fs/fs.o(.text.lock+0x18a): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x485): undefined reference to
`rwsem_down_read_failed'
fs/fs.o(.text.lock+0x49a): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x4a6): undefined reference to
`rwsem_down_write_failed'
fs/fs.o(.text.lock+0x4ba): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x4c6): undefined reference to
`rwsem_down_write_failed'
fs/fs.o(.text.lock+0x4da): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x4e6): undefined reference to
`rwsem_down_write_failed'
fs/fs.o(.text.lock+0x4fa): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x506): undefined reference to
`rwsem_down_write_failed'
fs/fs.o(.text.lock+0x51a): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x526): undefined reference to
`rwsem_down_write_failed'
fs/fs.o(.text.lock+0x53a): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x546): undefined reference to
`rwsem_down_write_failed'
fs/fs.o(.text.lock+0x55a): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x566): undefined reference to
`rwsem_down_write_failed'
fs/fs.o(.text.lock+0x57a): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x587): undefined reference to
`rwsem_down_read_failed'
fs/fs.o(.text.lock+0x59c): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x5a9): undefined reference to
`rwsem_down_read_failed'
fs/fs.o(.text.lock+0x5be): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x5cb): undefined reference to
`rwsem_down_read_failed'
fs/fs.o(.text.lock+0x5e0): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x5ed): undefined reference to
`rwsem_down_read_failed'
fs/fs.o(.text.lock+0x602): undefined reference to `rwsem_wake'
fs/fs.o(.text.lock+0x60f): undefined reference to
`rwsem_down_read_failed'
fs/fs.o(.text.lock+0x624): undefined reference to `rwsem_wake'
ipc/ipc.o(.text.lock+0xfc): undefined reference to
`rwsem_down_write_failed'
ipc/ipc.o(.text.lock+0x110): undefined reference to `rwsem_wake'
ipc/ipc.o(.text.lock+0x130): undefined reference to
`rwsem_down_write_failed'
ipc/ipc.o(.text.lock+0x144): undefined reference to `rwsem_wake'
drivers/char/char.o(.text.lock+0x49): undefined reference to
`rwsem_down_read_failed'
drivers/char/char.o(.text.lock+0x5e): undefined reference to
`rwsem_wake'
drivers/char/char.o(.text.lock+0x72): undefined reference to
`rwsem_wake'
make: *** [vmlinux] Error 1
I tried various things, e.g. downloading the latest libmm, copying
semaphore.h to /usr/include (the version in there was different), all to
no avail.
Any help would be greatly appreciated. Please cc. me (without the
NOSPAM) in any reply.
------------------------------
From: Rik van Riel <[EMAIL PROTECTED]>
Subject: Re: cache coherency, threads, SMP
Date: Mon, 7 May 2001 00:40:22 -0300
D. Stimits wrote:
> In an effort to write more efficient threaded code (x86), and
> considering cache thrashing, I'm interested in finding out
> more about the cache coherency scheme used in 2.2 and 2.4
> kernels. Is it a simple write-invalidate scheme?
> On a minor note, I'm curious how closely linux x86 SMP cache
> schemes are to other x86 UNIX style systems?
Cache coherency between different CPUs is completely done in
hardware (on x86). This means Linux and other Unices will be
using the same cache coherency scheme ;)
Btw, this is happening no a per-cacheline basis, using the MESI
protocol between CPUs.
--
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: disk request ordering dependency
Date: Sun, 6 May 2001 19:35:13 +0000 (UTC)
Zhiyong Xu <[EMAIL PROTECTED]> wrote:
> How did kernel enforce disk request dependency, for example, the rename
> operation changes the name of a file by adding a link for the new name and
> removing the old link. If the system goes down after the old directory block
> has been written(with the link removed) but before the new one is written,
> neither name for the file will exist.
> I checked __make_request function in ll_rw_blk.c, but I don't where's
> code deal with consistency of data block of a file and metadata of it. So
> what's the linux stratege here?
> Thanks!
I think that such consistency checks are done by softupdates on FreeBSD
but not by Linux. Maybe i am in error.
--
Michel Talon
------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Re: accessing memory and IO space
Date: Mon, 07 May 2001 09:57:59 +0200
[EMAIL PROTECTED] wrote:
>
> The need has arisen to be able to access arbritary memory and IO space while
> working on driver development for an embedded project. I am hoping that
> someone can tell me a way to either use gdb to read/write memory or IO space
> or barring that, a debug program that will read/write any memory address. I
> have read 'man gdb' and tried the 'x' command to no avail. Maybe it is as
> simple as giving gdb a command line argument that I don't know yet. I would
> have to believe that such a thing is easy, its just that I don't know how to
> do it in this operating system. In developing drivers on other architectures
> (such as vxWorks for instance), it is easy to read memory and IO space in
> order to check and possibly re-configure driver hardware while developing.
Hmm, I usually try patching memory with gdb
like
set *0x123456=0x9876
Is this what you want?
-Arne
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: disk request ordering dependency
Date: 7 May 2001 04:04:50 -0400
In article <9d491h$15t$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>Zhiyong Xu <[EMAIL PROTECTED]> wrote:
>> How did kernel enforce disk request dependency, for example, the rename
>> operation changes the name of a file by adding a link for the new name and
>> removing the old link. If the system goes down after the old directory block
>> has been written(with the link removed) but before the new one is written,
>> neither name for the file will exist.
>> I checked __make_request function in ll_rw_blk.c, but I don't where's
>> code deal with consistency of data block of a file and metadata of it. So
>> what's the linux stratege here?
Wrong layer. With synchronous mount that is done in filesystem itself by
explicit waiting - grep for wait_on_buffer. Async is async - no ordering
warranties. Journalling stuff uses ->b_end_io for notification of IO
completion; __make_request() has nothing to it.
>I think that such consistency checks are done by softupdates on FreeBSD
>but not by Linux. Maybe i am in error.
S-u is not implemented on Linux, but any implementation would do interesting
stuff on layers above __make_request().
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Moritz Franosch <[EMAIL PROTECTED]>
Subject: Re: programming the serial port
Date: 07 May 2001 10:52:18 +0200
[EMAIL PROTECTED] (Javier Loureiro Varela) writes:
> I'm coding some stuff with datagrams and my serial port
> I believe that there are some sites or some mailing list
> related for this issue... or even, a good reference book for all
> this...
>
> any suggestion?
In addition to the other sources, look at the following sections of
the libc documentation (info libc).
Low-Level Terminal Interface
Terminal Modes
Special Characters
It explains serial programming very well.
Moritz
------------------------------
From: "Barry Smyth" <[EMAIL PROTECTED]>
Subject: Re: losing bottom halves
Date: Mon, 7 May 2001 10:01:32 +0100
Thanks for the help,
I have transfered all my Bottom Half code directly into the isr, since the
bottom half cannot be guaranteed to execute before the next interrupt
arrives.
Barry
"Linus Torvalds" <[EMAIL PROTECTED]> wrote in message
news:9d0816$1sh$[EMAIL PROTECTED]...
> In article <9ctrqs$7bd$[EMAIL PROTECTED]>,
> Barry Smyth <[EMAIL PROTECTED]> wrote:
> >
> >I am writing a driver for a PCI card using interrupts. I have a main
> >interrupt service routine and inside this I schedule a bottom half to the
> >immediate task queue.
> >
> >Most of the time when running the program everything works fine, however
> >occasionally all the interrupts occur and the isr gets run but the bottom
> >half does not occur for every interrupt.
>
> That is correct.
>
> This is how bottom halves work. If you depend on the bottom half being
> called for each and every interrupt, you should just do the work in the
> interrupt handler itself, and not using the bh's at all.
>
> The whole point of bh's is to get a separate thread of execution that
> can be used to combine work over several interrupts, and that doesn't
> have any re-entrancy issues with interrupts.
>
> BH_IMMEDIATE only means that the kernel will try to run it as soon as
> possible: which _usually_ means that if your CPU is fast enough that it
> can easily keep up with the interrupt work + the bottom half work,
> you'll get a 1:1 relationship 99+% of the time.
>
> However, there are many reasons why you might not get a bh invocation
> every time, the main one being that you get interrupts quickly enough
> that the previous bh invocation hasn't even had time to finish (and it
> will NOT be re-entered until the next time around).
>
> There are other potential reasons - you might get the interrupt during
> another interrupt, or while bottom halves are locked out. Then they'll
> just be delayed.
>
> So your bottom half _should_ be able to handle the case of having to do
> the work from two (or many more) interrupts. Which is a case that you
> will see especially on slower machines. And that's where you'll really
> find this very useful: the bottom half handler can be written to
> efficiently handle larger amounts of data.
>
> This is what bottom halves were designed for - doing things like complex
> tty processing where the data can arrive so quickly that doing it one
> byte at a time in the interrupt handler is prohibitively expensive. So
> you'd have the real work done in the bottom half handler, which then
> handles a whole "burst" of data.
>
> Linus
------------------------------
** 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
******************************
