Linux-Development-Sys Digest #695, Volume #8 Sun, 6 May 01 18:13:15 EDT
Contents:
Re: Kernel 2.4.4 Problem Solved ("Fruitbat")
file_operations changed radically in 2.4!!?? ("yin wang")
CardBus card SIIG IEEE 1394 Support, anyone? ("Emu")
cache coherency, threads, SMP ("D. Stimits")
Re: file_operations changed radically in 2.4!!?? (Alexander Viro)
Re: md5sum'ing block devices (Tim Shoppa)
Q: device driver races? (Holger Eitzenberger)
"wake many" vs "wake one" in listen/accept ([EMAIL PROTECTED])
Re: Obtaining the IP address of the eth0 interface? ([EMAIL PROTECTED])
opening /dev/ttyS1 in kernel module (Tomasz Ochman)
Re: How to get a number of processors (Greg Copeland)
Re: Is linux kernel preemptive?? (Greg Copeland)
Re: programming the serial port (Ulrich Eckhardt)
Re: How to get a number of processors (Kaz Kylheku)
Re: Obtaining the IP address of the eth0 interface?
Re: opening /dev/ttyS1 in kernel module (Tomasz Ochman)
Understanding module initialization
Re: kernel debugger again and again (sorry) ("Alessandro Bietresato")
----------------------------------------------------------------------------
From: "Fruitbat" <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.4.4 Problem Solved
Date: Sun, 06 May 2001 04:51:14 GMT
I have solved my problem! I am using an SMC1211TX card, based on the realtek
8139 chip. It seems there may be a problem with the 8139too code in 2.4.4, I
recompiled my modules using the 8139too code from 2.4.3 and the problem has
disappeared.
It was strange as I could ping the NIC and my ADSL modem fine and ifconfig
showed the NIC ok, it just would not allow the ADSL modem to connect, an
lsmod of the modules showed about a 1k difference between the 8139too
modules (the greater figure used by 2.4.3 kernel version).
As I am not networked (apart from the ADSL modem) at the moment, I wonder if
I would have observed any network problems using the card and 2.4.4 module
on a network.
Any way hope this helps someone else out.
------------------------------
From: "yin wang" <[EMAIL PROTECTED]>
Subject: file_operations changed radically in 2.4!!??
Date: Sun, 6 May 2001 13:33:54 +0800
Hey,
I found that file_operations struct in <linux/fs.h> changed too much in
2.4 kernel source. It seems they added a first element named "module owner"
to it. This will make every module change their code to be compatable to
this!
------------------------------
From: "Emu" <[EMAIL PROTECTED]>
Subject: CardBus card SIIG IEEE 1394 Support, anyone?
Date: Sun, 6 May 2001 01:06:05 -0500
I would like to mount my hard drive from this adapter. I contacted the
maintainer for IEEE 1394 as suggested by David Hinds, the maintainer for
PCMCIA.
I have had no reply as of yet.
Can someone help me out or has anyone else tried this support for this type
of Card Bus Card?
Dell Inspiron 7500 Dual boot. WIn98SE and Red Hat Linux v7.1
Kernel 2.4.2 Monolithic
Red Hat Distro v7.1, with Ximiam's Gnome v1.4
------------------------------
Date: Sun, 06 May 2001 00:16:03 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: cache coherency, threads, SMP
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? If so, is it per cache line, or is it a cache
block scheme? I see that /proc/cpuinfo mentions each cpu's cache size,
but there is nothing of course to give finer detail, especially the size
of a single cache line (or cache block if coherency is not on a
line-by-line basis). Is there a consistent cache line size for PII's of
the same cache size? Is there a consistent cache line size for PIII's or
P4's of the same cache size? Better yet, is there some means that might
allow me to detect cache line (or cache block) size for more efficient
threading practices? If this is all inconsistent, maybe there is a
common largest cache line or cache block size, e.g., 64 bytes...what is
the advised means of dealing with cache detection?
On a minor note, I'm curious how closely linux x86 SMP cache schemes are
to other x86 UNIX style systems?
D. Stimits, [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: file_operations changed radically in 2.4!!??
Date: 6 May 2001 03:01:29 -0400
In article <9d2ns7$29a$[EMAIL PROTECTED]>, yin wang <[EMAIL PROTECTED]> wrote:
>Hey,
> I found that file_operations struct in <linux/fs.h> changed too much in
>2.4 kernel source. It seems they added a first element named "module owner"
>to it. This will make every module change their code to be compatable to
>this!
Yes. It also closes a heap of oopsable races. BTW, you can remove
MOD_{INC,DEC}_USE_COUNT from ->open() and ->release() for character devices
now.
There is no promise of binary (or even source) compatibility
between different stable branches. Never was. If you maintain kernel
code (and modules are such code) - be ready to do it.
Interfaces changed. Interfaces will change. Accept it or not,
that's how it works.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Date: Sun, 06 May 2001 05:47:29 -0400
From: Tim Shoppa <[EMAIL PROTECTED]>
Subject: Re: md5sum'ing block devices
Loris Caren wrote:
> However, I'm still baffled how reading beyond the end of the data can work
> perfectly on one drive but not on another, same kernel, same driver (both
> SCSI).
CD-R's (and even some pressed CD's) often have a few to several more
"almost good" 2048-byte blocks past the intended end-of-data point.
These "almost good" blocks may read on some drives, but not on others.
Even on the same drive you can sometimes get different results,
because this is nasal demon territory.
The solution you found - finding the originally-intended end-of-data
and then using dd to make sure you don't go beyond it - is the
preferred one.
Tim.
------------------------------
From: [EMAIL PROTECTED] (Holger Eitzenberger)
Subject: Q: device driver races?
Date: Sun, 6 May 2001 13:17:08 +0200
Hi,
I am about to develope a device driver for a LED board which is
connected to the PC parport. This driver is implemented on top of the
kernel "parport.o, parport_pc.o" modules in order to prevent other
device drivers to talk to this parport simultanously.
This LED boad monitors system activity (network traffic, ...).
Additionally there is a feature on the board called "reset cylcle".
At boot time a reset cycle is started and has to be stopped in a
(configurable) time period; if not, the system will be rebooted by the
LED board.
A reset cycle can be started/stopped by setting certain bits on
the PP_CTRL byte of the parport IO bytes. The reset cycle can be
controlled through a userlevel program by using ioctl().
(ioctl(fd, LED_RESET, /* 0: stop, 1: start) */).
The six LEDs on the board can be controlled by setting a bit on the
PP_DATA IO byte of this particular parport.
Are there any race conditions in accessing the parport IO bytes
simultanously? Since certain parts of the linux kernel (e.g. ip_rcv()
in ./net/ipv4/ip_input.c) are patched to write bytes to the PP_DATA IO
byte, and the userlevel program may write to the PP_CTRL IO byte in
another process, are there any race conditions in there?
Do all these routines need to [a]
parport_claim_or_block();
/* access IO bytes */
parport_release();
use before writing? Since some of the accesses sit in an interrupt
handler i can't use [a], right? Do i need to put this code into a BH?
Thanks in advance.
Holger
--
+++ Debian GNU/Linux <[EMAIL PROTECTED]> +++ ICQ: 2882018 +++
++ GnuPG Key -> http://www.t-online.de/~holger.eitzenberger ++
------------------------------
From: [EMAIL PROTECTED]
Subject: "wake many" vs "wake one" in listen/accept
Date: 6 May 2001 11:00:04 GMT
I'm trying to figure out the right way to use the "wake one" semantics
for listen/accept in 2.4. In Apache 1.3.19 I find these comments:
/* On some architectures it's safe to do unserialized accept()s in the single
* Listen case. But it's never safe to do it in the case where there's
* multiple Listen statements. Define SINGLE_LISTEN_UNSERIALIZED_ACCEPT
* when it's safe in the single Listen case.
*/
Is there a problem with using "wake one" when a process has more than
one socket being listened (with non-blocking accept), or is this
something that's just a problem inside Apache?
I'm planning to implement a daemon which could benefit from "wake one"
but I want to be sure I don't "plan in" something that ends up making
this not work right.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Obtaining the IP address of the eth0 interface?
Date: 6 May 2001 11:07:22 GMT
On Sun, 06 May 2001 03:07:26 -0000 [EMAIL PROTECTED] wrote:
| In article <[EMAIL PROTECTED]>,
| Carlos Justiniano <[EMAIL PROTECTED]> wrote:
|
|>IP and IFCONFIG both return the correct information of the interfaces
|>that are active. I realize that I could parse the output to obtain
|>the IP info that I need... but I'm more interested in a solution that
|>doesn't depend on a clever trick. I imagine that there must be an API
|>to enumerate the active interfaces?
|
| Why not look at the source of ifconfig? Surely that'll give you
| the answer.
Another approach is to run the program of interest through strace
and see what functions it calls near where the interesting output
is. If the man pages for what you see don't tell you what to do,
such as the case with ioctl() symbols, at least you'll be armed
with some symbol names to grep for in program and kernel source.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: Tomasz Ochman <[EMAIL PROTECTED]>
Subject: opening /dev/ttyS1 in kernel module
Date: 6 May 2001 16:36:21 GMT
Hi.
Is it possible to open, read, write and close /dev/ttyS1 in kernel module?
When I try to compile my module gcc write:
ptmcom.c:108: warning: implicit declaration of function `read'
ptmcom.c:109: warning: implicit declaration of function `open'
ptmcom.c:110: warning: implicit declaration of function `write'
ptmcom.c:111: warning: implicit declaration of function `close'
and I cannot load it.
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 06 May 2001 12:01:51 -0500
[EMAIL PROTECTED] (Eric P. McCoy) writes:
> Greg Copeland <[EMAIL PROTECTED]> writes:
>
> > Oddly enough, my man page for sysconf doesn't show the _SC_NPROCESSORS_CONF
> > option. Hmm....wonder how long it's been around.
>
> It starts with an underscore, which probably means it's nonstandard.
> I'd be a little stronger and say that if it's not in the man page,
> you also shouldn't use it.
>
> This strikes me as a battle of bad ideas: I hate writing a text parser
> to deal with /proc; I don't like using nonstandard pieces of code; and
> no program should ever need to know how many processors are in a given
> box. There are cases where you'd want to use one or all of these bad
> ideas, but I, for one, would need a pressing reason.
>
I strongly disagree with the assertion that no one would ever need to know
how many processors there are in a system. I have worked on some large UNIX
boxes and needed to know how may there were. I took the short path made it
a user determined value, but making it dynamic would of been nicer. BTW, it
was for parallelizing some computations and the number parallel index
optimizations that could be run at a single time while still allowing for
free CPU's to handle from other batch jobs. In short, if I exceeded more
than 75% of the CPU's (rounded down), the batch jobs suffered too heavily. As
you can see, making it dynamic would of been nice since it had to run on
several different size boxes (4 and 8 CPU machines). Keep in mind, some of
these batch jobs would run for 8-18 hours. If I took the other CPU's,
it would force them to run over their maximum run-time window, which was
18-hours. If I didn't take enough, I wouldn't finish in the required
window. I would of rather had someone be able to say 50% or 75% of the CPUs
should go here, than a hard number, as I did do, which required unique config
files on each system. At any rate, I don't think it's wise to assert such a
rule should exist.
--
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: 06 May 2001 12:23:53 -0500
[EMAIL PROTECTED] (Neal Tucker) writes:
>
> Your statement that "system calls can preempt each other" is
> correct if one uses your personal definition of system calls
> ("any function in the kernel"), but incorrect according to the
> widely-accepted definition of "system call".
>
> If you want to have an intelligent discussion about such things,
> you have to agree on terminology. If you can pick whatever
> terminology you want, you could argue *any* position, but it
> would be meaningless. As an example, I can defend the statement
> that "system calls are fluffy and sweet" if I define "system
> call" to mean "cotton candy".
>
I completely agree. This is why I went on to define what I was
referring to. I did this because I knew I was not using a
standard definition and hoped this would clarify my comments, thus,
having a common definition. It was seemingly ignored. In fact,
a more technical description ensued, which was without need and
added nothing to the conversation other than letting us know that
the author knew what he was talking about, which was not being
questioned in the first place.
As for the laymen reference, many people read this group so they
can learn something. I know I do. Many people may not care
enough to know every nut and bolt, however, they may want enough
to answer their basic question. I'm assuming that you have a
boss? Don't know about you, but I've spoken with MANY, MANY,
MANY people where half-truths are good enough because the whole
truth is beyond comprehension and/or without desire to understand.
I do not believe that my comments were unwarranted or missed
the intended audience.
Nuff said already. This horse has long since been beaten to
death.
At any rate, point taken. I will, hence forth in this group,
assume that everything is a very detailed conversation and dot
every "i".
Thanks,
Greg
--
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: Ulrich Eckhardt <[EMAIL PROTECTED]>
Subject: Re: programming the serial port
Date: Sat, 5 May 2001 22:15:24 +0200
Javier Loureiro Varela wrote:
> any suggestion?
>
check out the serial-HOWTO and the serial-programming-HOWTO
uli
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to get a number of processors
Reply-To: [EMAIL PROTECTED]
Date: Sun, 06 May 2001 19:59:05 GMT
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
:)
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Obtaining the IP address of the eth0 interface?
Date: Sun, 06 May 2001 20:09:24 -0000
In article <9d2ftd$15mu$[EMAIL PROTECTED]>, greg <[EMAIL PROTECTED]> wrote:
>>Why not look at the source of ifconfig? Surely that'll give you
>>the answer.
>A quick parsing of /proc/net/dev should be enough (that's what ifconfig does
>actually).
True, but I was trying to point out how to solve this sort of problem
in general rather than just posting the answer. Way too often I see
someone asking how to do something that <pick a utility> does when source
is available and the answer is easy to find. Certainly the answer would
come fast than posting and waiting for a reply.
--
http://www.spinics.net/linux
------------------------------
From: Tomasz Ochman <[EMAIL PROTECTED]>
Subject: Re: opening /dev/ttyS1 in kernel module
Date: 6 May 2001 20:54:22 GMT
Tomasz Ochman <[EMAIL PROTECTED]> wrote:
> Hi.
> Is it possible to open, read, write and close /dev/ttyS1 in kernel module?
> When I try to compile my module gcc write:
> ptmcom.c:108: warning: implicit declaration of function `read'
> ptmcom.c:109: warning: implicit declaration of function `open'
> ptmcom.c:110: warning: implicit declaration of function `write'
> ptmcom.c:111: warning: implicit declaration of function `close'
> and I cannot load it.
I've forget #define __KERNEL_SYSCALLS__
Now my module work and question is not actual.
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Understanding module initialization
Date: Sun, 6 May 2001 14:26:11 -0700
I am trying to understand how modules are initialized in the kernel. I can
see in ../init/main where do_basic_set for things like CONFIG_PCI and other
constants. After that I see a call to do_initcalls() where I then presume
the various init_module() routines of all of the modules that are compiled
into the kernel are called. I can see it calling something called
__initcall_start which appears defined in vmlinux.lds and appears to be a
linker control script of some sort. The problem is I don't understand what
is going on. Perhaps someone might help me out by expressing how this works.
(And if the answer is 'man xxx', so be it, but I did try).
By extension, the next question relates to modules loaded after the kernel
boots. Is this the same, or is there some other mechanism at work.
Charles
------------------------------
From: "Alessandro Bietresato" <[EMAIL PROTECTED]>
Subject: Re: kernel debugger again and again (sorry)
Date: Sun, 6 May 2001 23:45:01 +0200
"Massimiliano Caovilla" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:[EMAIL PROTECTED]...
> hello again,
> I'm sorry to bother but I really feel this question.
> I need a way to debug a kernel module wich makes use of kernel threads,
> I have some lock problems wich are very hard to track without (let's
> say) a threadlist or something like solaris adb. I've been pointed to
> chech pice and some kernel debugging patch, but they all don't work /
> result unusable. What is the OFFICIAL linux kernel debugging way? There
> MUST be a way to debug a module!!! I'm opened to all possibilities,
> please just suggest me one. Should I write to Linus directly to get
> hints about this?? I don't want to annoy him!!!!
>
> Ciao
> Massimiliano
Hello Massimiliano,
i'm posting this in italian due to my bad english... :-(
Ho gi� visto altri quesiti circa le tematiche del debugging di un
kernel-module, ma non ho mai visto tuttavia una soluzione UFFICIALE.
Qui sotto ti elenco alcune delle risorse che ho trovato in giro per la rete,
(anche se temo che siano le soluzioni che hai gi� provato senza successo)
ed alcune mie considerazioni.
Link utili:
http://www.linuxdoc.org/LDP/khg/HyperNews/get/khg/15.html (molto datato)
http://user-mode-linux.sourceforge.net
in qusto sito si parla di alcune patch al kernel di linux che permettono di
avviare un nuovo kernel in user-mode
all'interno di un kernel gi� funzionante, e di effettuarne quindi il
debugging con gdb. Da come viene descritta
la cosa non mi sembra una gran soluzione.
http://oss.sgi.com/projects/kdb
descrive una patch al kernel (versioni 2.2.x, 2.3.x e 2.4.x) che permette di
includere un debugger nativo
all'interno del kernel stesso (sembrerebbe ci� che cerchi).
Nota: sono supportate le piattaforme i386 ed IA64. (molto recente)
http://oss.sgi.com/projects/kgdb
sempre dalla Silocon Graphics. Viene presentata una patch al kernel che
permette di farne il debugging da una macchina remota collegata su linea
seriale ed utilizzante il normale GDB (http://www.gnu.org/software/gdb).
(molto recente).
Per quanto mi riguarda, ho scritto un (semplice) file-system driver per
Linux ed ho
risolto il problema
del debugging utilizzando la funzione printk; leggendo tuttavia il tuo
messaggio del 19/04
questa soluzione non si � dimostrata utile al tuo caso a causa di difficolt�
nel tracciare il flusso del programma.
Delle tre soluzioni realistiche di cui sono a conoscenza (il debugger nativo
del kernel, quello remoto via
seriale e quello del tracciamento mediante printk) nessuna pare adatta al
tuo problema. Vorrei comunque
sottoporti alcune considerazioni, sperando che ti siano di qualche utilit�.
Partendo dalla printk, ti sei trovato in difficolt� nel tracciare il flusso
del modulo, probabilmente a causa del
gran numero di thread che sono in funzione. Potresti provare a formattarle
in modi opportuni (ad esempio
presentando l'identificativo del thread) e costruire un'apposita utilit� che
analizzi l'output del modulo (ti ricordo che
il demonoe kernel logger salva i messaggi del kernel, printk comprese, in
/var/log/messages).
Una seconda possibilt� potrebbe essere quella di non richiamare direttamente
le funzioni di gestione dei kernel-trhead,
ma di chiamare delle funzioni intermedie, che effettuino dei controlli
preliminari prima di richiamare le funzioni vere e proprie.
In questo modo dovresti essere in grado di identificare la causa dei tuoi
problemi di lock.
Altro tentativo che potresti fare, se la logica del tuo modulo te lo
consente, � quella di scrivere una applicazione normale
(in user-space) che simuli il comportamento dei thread creati dal tuo
modulo, e quindi utilizzare un normale debugger.
Io non utilizzato gdb direttamente, ma dall'interno dell'ambiente di
sviluppo kdevelop, che trovo molto comodo.
Infine, � possibile analizzare l'intera memoria del kernel in esecuzione,
utilizzando alcuni device particolari. La cosa pu�
inoltre venire semplificata dall'ausilio di alcune apposite librerie. Questa
tecnica potrebbe permetterti di analizzare le
strutture relative ai thread di tuo interesse; viene presentata in un
recente numero della rivista Computer Programming (o DEV, non ricordo
esattamente), della Edizioni Infomedia. Qualora fossi interessato ad
ulteriori dettagli potrei cercarti l'articolo e mandartene un sunto.
Spero che questi suggerimenti possano esserti di una qualche utilit�, buon
lavoro.
Alessandro Bietresato
[EMAIL PROTECTED]
------------------------------
** 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
******************************
