Linux-Development-Sys Digest #704, Volume #7 Fri, 24 Mar 00 14:13:15 EST
Contents:
Re: Absolute failure of Linux dead ahead? (Dale Pontius)
Re: Absolute failure of Linux dead ahead? (Josef Moellers)
clarification question on queues and bh ("Aurelie Fonteny")
Re: Absolute failure of Linux dead ahead? (Mike)
Re: help - byte aligned vs. word aligned structures using gcc... (Bryan Hackney)
Re: system hung when compiling kernel (Anders Larsen)
Re: large numbers of open sockets (Tony R. Bennett)
Re: ncr53c801 stopped working in 2.3.xx (bill davidsen)
Re: Absolute failure of Linux dead ahead? (Kaz Kylheku)
Re: UART overrun errors (Villy Kruse)
Re: Plug and Pray PCI Modem support (John Brookes)
Re: UART overrun errors (Villy Kruse)
Problem with insmod and rmmod (Timur Tabi)
Re: UART overrun errors (Kaz Kylheku)
Re: Absolute failure of Linux dead ahead? (Matthias Warkus)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dale Pontius)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 24 Mar 2000 16:10:20 GMT
In article <[EMAIL PROTECTED]>,
Warren Young <[EMAIL PROTECTED]> writes:
>
> Even C++, the closest cousin of C available, gets shunned a lot.
> Several Open Source projects started in C++ and were later converted to
> C, not because of the language itself, but to get more outside
> developers. Consider also projects like Glade, which builds C code by
> default: there's an addon (glade-- - note the "--" ha-ha-only-kidding
> suffix) that does C++ code, but it lags behind the C version.
>
C++ is a close cousin from a source perspective, but once you get
into OO extensions, it becomes a pain to link to.
> Face it, there's a prejudice in favor of C. It can't be considered
> anything other than prejudice, because logical arguments in favor of
> other languages fail regularly.
And I'll assert that it's because of the linkage problems. ANYTHING
in the world can link to C. The same can't be said of C++, if anything
it's the exact opposite. Doing your project in C++ pretty much mandates
that all surrounding and derived work be done in C++, as well.
It's one of my biggest beefs with KDE, because I've always been a fan
of Wirth's work, and I don't like seeing it locked out. (By C++)
Dale Pontius
NOT speaking for IBM
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Fri, 24 Mar 2000 17:13:10 +0100
Kaz Kylheku wrote:
> =
> On Fri, 24 Mar 2000 15:05:10 +0100, Matthias Warkus <[EMAIL PROTECTED]> wr=
ote:
> >It was the Thu, 23 Mar 2000 22:52:45 +0100...
> >...and Mario Klebsch <[EMAIL PROTECTED]> wrote:
> >> [EMAIL PROTECTED] (Matthias Warkus) writes:
> >>
> >> >> The problem with Pascal, as distinct from the others, is that the=
> >> >> design just wasn't made for anything more than education.
> >> >...
> >> >e) No pointers to functions AFAIK
> >>
> >> At least they were possible as arguments to function/procedure
> >> calls. I am not sure, wether they are possible as stand alone
> >> variables or as structure members. However, there were a lot pascal
> >> compilers in use, that did not implement procedure arguments.
> >
> >If pointers to functions exist, then there's another e):
> >
> >e) No variable length argument lists for you.
> =
> Well, C didn't have these either, initially. People did it anyway, as =
a a
> complete platform specific hack, relying on the lack of type checking i=
n C and
> the local stack layout. Andrew Koenig introduced <varargs.h> but it was=
not
> until ANSI C that we got the ellipsis punctuator and <stdarg.h>.
Can anyone give a substantial reason why we would need all these
"features" to write an operating system in, other than "C has them, so
any language used to write an operating system in should have them too?"
E.g. how many kernel functions rely on variable arguments? Hold this
against the question: how many bugs have been found that were caused by
a function not providing the necessary number of arguments?
C has evolved from something that was nothing more than a beefed up
assembler, and, as such, has numerous structures that resemble
assembly-like features. However, I'd like to argue that
1. If you do want to write a new operating system (no, not YAUC), you'd
do so from scratch.
2. If you did the design from scratch, you might just use proper tools
that might aid in proper software design and implementation.
3. Since, accoring to some theorem the name of which I have forgotten,
most, if not all, languages are equivalent.
The only reason I see to keep using C is the vast code-base. Not just
the drivers, but the applications as well: most (all) GNU tools are
written in C and those that access kernel structures can use common
header files to do so. So rather than elaborately mimic the layout of
data structures to fit kernel and user land together, both should use
the same language.
-- =
Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1
------------------------------
From: "Aurelie Fonteny" <[EMAIL PROTECTED]>
Subject: clarification question on queues and bh
Date: Fri, 24 Mar 2000 09:55:14 -0600
I just want to make sure I'm not mistaken in waht I understand. Please tell
me if I am.
- dev_queue_xmit in net/core kernel 2.2 :
We do a start_bh_atomic() at the beginning of the routine and an
end_bh_atomic() at the end, which means that there is no real queuing done
in the device drivers, and if three packets arrive, one of which is for PPP,
the second of which is for Ethernet, the third of which is for PPP, the
second will have to wait for the first end_bh_atomic() to be processed, and
same thing for the third packet : no queing is done and two device drivers
can't be busy at the same time unless the dev->tbusy is set for one of those
devices or one network device driver returned before being able to send the
whole frame it was handling.
If so, where is queuing part done if it is not at the network device drivers
level?
Is there a specific reason why there is no real queuing done at the network
device drivers level?
-dev->tbusy
This lock is set only when a whole frame couldn't be pushed from the network
device driver to the physical layer and other frames are waiting for this
device driver. What would usually be the reasons for such a case (whole
frame can't be pushed rigth now to the physical layer)?
- mark_bh / net_bh() :
When dev->tbusy is set, this means that we are going to run the queues. When
we run net_bh(), bh_active is set but not global_bh_count (lock from
start_bh_atomic()), or I don't see where... : so my question is : say there
are 10 packets in the PPP device driver queue when we're running queues : so
we dequeue them and process them in net_bh(), but what happens if some other
packets come at the very same time for PPP : since the global_bh_count is
not incremented then with start_bh_atomic(), can the first packet be
processed by dev_queue_xmit and enqueued while we're running queues?
Thanks for your time
Aurelie
------------------------------
From: Mike <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Fri, 24 Mar 2000 10:29:02 -0500
The Ghost In The Machine wrote:
>
> In comp.os.linux.advocacy, Geoff Lane <[EMAIL PROTECTED]>
> wrote on Fri, 17 Mar 2000 11:59:05 +0000 <9m6ta8.7kp.ln@twirl>:
> >In article <[EMAIL PROTECTED]>,
> > Bill Godfrey <[EMAIL PROTECTED]> writes:
> >> Use a standard library where time_t is a 64 bit signed integer (the new
> >> C standard requires such an integer type) and keep using C. No need to
> >> change languages.
> >
> >There are many reasons to keep C out of inexpert hands ( and there's only
> >about 5 experts - three of whom devised the language!)
>
> Would you rather we rewrite the kernel in Fortran or COBOL? :-)
>
> [.sigsnip]
>
> --
> [EMAIL PROTECTED] -- insert random misquote here
Hey! How about BASIC! ;->
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: help - byte aligned vs. word aligned structures using gcc...
Date: Fri, 24 Mar 2000 10:21:26 -0600
Robert Nickel wrote:
>
> Can anyone tell me how to make a structure byte-aligned instead of word
> aligned?
>
> I'm using a structure as the layout for an mmaped region of /dev/mem and
> need to make sure that my structure is kept in order.
>
> I'm certain this is trivially simple, but I'm (again) without the know how
> on this one.
>
> Thanks,
> --Robert
Please provide the structure in question.
There are gcc extensions that are alignment directives, but it is often
safer and easier to to your own packing and unpacking.
--
Bryan Hackney / BHC / [EMAIL PROTECTED]
http://www.FreeClassAds.com/
http://bhconsult.com/
http://bhconsult.com/bh/pgp.key
------------------------------
From: Anders Larsen <[EMAIL PROTECTED]>
Subject: Re: system hung when compiling kernel
Date: Fri, 24 Mar 2000 17:37:58 +0100
Karsten Bickel wrote:
>
> i've got a strange problem compiling my kernel:
>
> I installed a SuSe 6.0 distribution on my AMD 386DX2/80 with 8 MB RAM.
> (realy, no joke).
Gotta be a joke!
It's probably a 486.
> Now I tried to build my first own kernel based on the kernel-sources
> 2.0.36.
>
> All works fine till the point gcc tries to compile 'ide.c'. It starts
> compiling and then the system(!) hung. Nothings works (e.g. switch to
> another virtual console, numlock key, ...) - the only exit is a hard reset
> or power off/on.
>
> I tried it several times - exactly the same.
> I reinstalled the sources, compiler, libraries - exactly the same.
>
> Any suggestions?
> Do you need more info?
That's common behaviour when the system runs out of memory.
If you can't add RAM, you must increase the available swap space.
have fun
Anders Larsen
------------------------------
From: [EMAIL PROTECTED] (Tony R. Bennett)
Subject: Re: large numbers of open sockets
Date: 24 Mar 2000 08:43:13 -0800
In article <[EMAIL PROTECTED]>,
P.G.Hamer <[EMAIL PROTECTED]> wrote:
>Chris Green wrote:
>
>> Are there going to be any problems with an application
>> (running on a large linux system w/ lots of ram and processor amd
>> internet connection bandwidth) that might have something like 50K
>> simultaneous open stream sockets? Traffic through each socket will be
>> fairly low, and intermittent. The app would use poll() to wait for
>> requests, and then dispatch the requests to different threads. I know
>> I could use some multiplexing scheme w/ udp to get around the huge #
>> of connections, but there are good reasons to do it with stream
>> sockets, if practical.
>
>Is the population of connections constant or changing? If the latter you
>could have problems with the delay (several mins) before you can re-use
>a host.port.protocol.port.host combination.
>
>Peter
>
Unless you use setsockopt() with SO_REUSEADDR...
--
Anti-spam filter: I am not root@localhost
trb@teleport dot com COM Public Access User --- Not affiliated with Teleport
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: linux.dev.scsi,linux.act.scsi
Subject: Re: ncr53c801 stopped working in 2.3.xx
Date: 24 Mar 2000 17:14:23 GMT
In article <[EMAIL PROTECTED]>,
Thomas Huber <[EMAIL PROTECTED]> wrote:
| I wanted to try out kernel 2.3.51/2.3.99-pre1 and with both
| my NCR 53C801 SCSI Controller doesn't work any more.
| With Linux-2.2.13 it works like a charm:
This may be related to shared memory being broken in 2.3.5x, a mount of
an shm filesystem is now required. No one bothered to include a patch to
put this in fstab, so the default is to fail.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
When taking small children to a carnival, always have them go potty
*before* you let them go on the rides, and let them eat all the junk
food and candy *after*.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 24 Mar 2000 17:26:15 GMT
On Fri, 24 Mar 2000 17:13:10 +0100, Josef Moellers
<[EMAIL PROTECTED]> wrote:
>Can anyone give a substantial reason why we would need all these
>"features" to write an operating system in, other than "C has them, so
>any language used to write an operating system in should have them too?"
>E.g. how many kernel functions rely on variable arguments? Hold this
I can think of one, that has a huge fan-in, namely printk.
Also, sprintf is handy in kernel programming. Look at all the functions that
generate the /proc stuff.
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: UART overrun errors
Date: 24 Mar 2000 17:52:18 GMT
On Fri, 24 Mar 2000 09:26:47 +0000,
Etienne Lorrain <[EMAIL PROTECTED]> wrote:
>
> The problem is that BIOS manufacturers (standart BIOS, video BIOS,
> SCSI BIOS...) do not want the user to view their assembly code, with
> a debugger or another way - so they make (nearly) impossible to trace
> or single step their code. I suspect they are not only disabling
> interrupts but also relocate the interrupt table (l/sidt assembly
> instruction) and put the stack in an un-useable state, like pointing
> in ROM. Their BIOS is not necessarily optimised (it maybe the first
> reason they do not want us to see it) so it takes quite a long time
> with interrupts disabled...
>
But that is not relevant for linux as it does not use BIOS for any
device access anyway. The linux code is open so you can actualy see
for yourself. There is a function in BIOS that is used, however, and
that is accessing the PCI configuration information, and possible also
the sleep and power management functionality.
Villy
------------------------------
From: John Brookes <[EMAIL PROTECTED]>
Subject: Re: Plug and Pray PCI Modem support
Date: Fri, 24 Mar 2000 17:54:42 +0000
==============83787D991AEA9BBA1D46C5E8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Afternoon folks,
student wrote:
> since everything that is pci is a form of pnp, the configuration of your
> modem is done entirely by software, either your bios or your os. if you
> want the details of setting up your pci modem in linux, check my web
> page. the page was written specifically for 3com modems, but it applies
> to any controller-based pci modem.
> http://members.xoom.com/mhpatters/comp/hardware/5613conf.htm
That's all very well and good, but the answer to the question is slightly
different (and much simpler) if his card is a winmodem: No, there is no
kernel support (nor is their likely to be in the near future). See
http://www.linmodems.org/ for more details. It claims there may be drivers
for (a?) PCTel modem(s?) and Lucent is said to have a binary-only kernel
module. The problem seems to be that (unlike winprinters) it's not just a
case of sorting out the protocol - you have to code all the DSP stuff as
well.
If I'm behind the times (it's been a couple of months since I last actively
checked), I trust someone will point out the error of my ways. Nonetheless,
the link is a good place to check if you've got a winmodem.
HTH,
JB
>
>
> MHP
>
> Crasy1_69 wrote:
>
> > Is there a kernel that supports PCI Plug and Pray modems?
> >
> > --
> > Posted via CNET Help.com
> > http://www.help.com/
--
John Brookes
Manchester Computing
University of Manchester
[EMAIL PROTECTED]
Tel: (0161) 275 7029
blah, blah.......does not reflect the views........blah
==============83787D991AEA9BBA1D46C5E8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Afternoon folks,
<p>student wrote:
<blockquote TYPE=CITE>since everything that is pci is a form of pnp, the
configuration of your
<br>modem is done entirely by software, either your bios or your os. if
you
<br>want the details of setting up your pci modem in linux, check my web
<br>page. the page was written specifically for 3com modems, but it applies
<br>to any controller-based pci modem.
<br><a
href="http://members.xoom.com/mhpatters/comp/hardware/5613conf.htm">http://members.xoom.com/mhpatters/comp/hardware/5613conf.htm</a></blockquote>
That's all very well and good, but the answer to the question is slightly
different (and much simpler) if his card is a winmodem: No, there is no
kernel support (nor is their likely to be in the near future). See <A
HREF="http://www.linmodems.org/">http://www.linmodems.org/</A>
for more details. It claims there may be drivers for (a?) PCTel modem(s?)
and Lucent is said to have a binary-only kernel module. The problem seems
to be that (unlike winprinters) it's not just a case of sorting out the
protocol - you have to code all the DSP stuff as well.
<p>If I'm behind the times (it's been a couple of months since I last actively
checked), I trust someone will point out the error of my ways. Nonetheless,
the link is a good place to check if you've got a winmodem.
<p>HTH,
<p>JB
<blockquote TYPE=CITE><a
href="http://members.xoom.com/mhpatters/comp/hardware/5613conf.htm"></a>
<p>MHP
<p>Crasy1_69 wrote:
<p>> Is there a kernel that supports PCI Plug and Pray modems?
<br>>
<br>> --
<br>> Posted via CNET Help.com
<br>> <a href="http://www.help.com/">http://www.help.com/</a></blockquote>
<pre>--
John Brookes
Manchester Computing
University of Manchester
[EMAIL PROTECTED]
Tel: (0161) 275 7029</pre>
<pre>blah, blah.......does not reflect the views........blah</pre>
</html>
==============83787D991AEA9BBA1D46C5E8==
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: UART overrun errors
Date: 24 Mar 2000 18:11:39 GMT
On Wed, 22 Mar 2000 16:36:30 +0100,
Mats Byggmastar <[EMAIL PROTECTED]> wrote:
>Hello,
>
>I'm working with some serial port code and (again) run into problems.
>I open a port (/dev/ttyS0) at 115200 bps. Data is sent/received over
>the port at a steady 64 kbit/s. I've also tried using lower speeds.
>However, the port don't seem to be very reliable. As soon as there is
>some disk activity, I immediately receive errors in my data stream.
>Either bytes are lost or random bytes are inserted into the received data
>stream. Checking in /proc/tty/driver/serial I see that a 16550A UART is
>used. I can also see that the errors are registered as overrrun errors.
>
>Does this mean that the interrupt that the 16550A issues isn't served by
>the driver in time and the FIFO gets overwritten?
>
>To eliminate the possibility that I could be picking up external noise
>on the null-modem cable I tested the port in loopback, TX pin connected
>to RX pin, with a very short wire. The problem was still there.
>
>Anyone has some ideas what is going on?
>
It is possible that the IRQ is misconfigured for the port in question,
but in that case you shouldn't expect anything to work properly. It is
said that you can use a 16550 port without interrupt support at normal
typing speed, that is not more than 100 bits per second.
I once tried to make a ppp connection at 345600 bps on a 50Mhz 486,
and it worked properly. There were in this case no modem to slow the
efective data rate down to 50 or 60 kbps. You do need to make sure that
the user level program can take the data at that speed or something is
lost somewhere.
The 345600 bps should generate an interupt once every 16 bytes or
approximately 2 every milisecond. A 64kbs data stream should generate 400
interupts for each second. The timer tick normaly produces 100 interupts
each second. That should be within the ability of most systems.
Disk interrupts would only occure once per full disk block written, and if
you use a SCSI disk controller with DMA or bus masterning the influence
from the disk system should be minimal. IDE disk using programed io
woule put more load on the CPU, but these days you can get IDE systems
that can do DMA as well.
Villy
------------------------------
From: Timur Tabi <[EMAIL PROTECTED]>
Subject: Problem with insmod and rmmod
Date: Fri, 24 Mar 2000 18:06:49 GMT
I'm using Rubini's book "Linux Device Drivers", and I've come across a
problem with the first example. The driver compiles and insmod works
fine (I get the "Hello world" message), but rmmod doesn't work. Here's
what I get:
[root@linux hello]# rmmod hello.o
rmmod: module hello.o not loaded
[root@linux hello]# insmod hello.o
hello.o: a module named hello already exists
So which is it? Is hello.o loaded or not? And if it is, how do I unload
it?
Here's the source code:
#define MODULE
#include <linux/module.h>
int init_module(void)
{
printk("<1>Hello, world\n");
return 0;
}
void cleanup_module(void)
{
printk("<1>Goodbye cruel world\n");
}
--
Remove "nospam_" from my email address when replying
Timur "too sexy for my code" Tabi, [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: UART overrun errors
Reply-To: [EMAIL PROTECTED]
Date: Fri, 24 Mar 2000 18:20:34 GMT
On Wed, 22 Mar 2000 16:36:30 +0100, Mats Byggmastar <[EMAIL PROTECTED]>
wrote:
>Hello,
>
>I'm working with some serial port code and (again) run into problems.
>I open a port (/dev/ttyS0) at 115200 bps. Data is sent/received over
>the port at a steady 64 kbit/s. I've also tried using lower speeds.
>However, the port don't seem to be very reliable. As soon as there is
>some disk activity, I immediately receive errors in my data stream.
>Either bytes are lost or random bytes are inserted into the received data
>stream. Checking in /proc/tty/driver/serial I see that a 16550A UART is
>used. I can also see that the errors are registered as overrrun errors.
The 16550A UART only buys you the ability to transfer several bytes at a time
rather than using one interrupt for each bytes.
Ultimately, you still need to use hardware flow control. Are you doing that?
>Does this mean that the interrupt that the 16550A issues isn't served by
>the driver in time and the FIFO gets overwritten?
If you can't use flow control, real time response is needed to not miss the
arrival data. Linux is not a real time OS.
------------------------------
From: [EMAIL PROTECTED] (Matthias Warkus)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Fri, 24 Mar 2000 18:25:41 +0100
Reply-To: [EMAIL PROTECTED]
It was the Fri, 24 Mar 2000 15:47:06 GMT...
...and Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> On Fri, 24 Mar 2000 15:05:10 +0100, Matthias Warkus <[EMAIL PROTECTED]> wrote:
> >It was the Thu, 23 Mar 2000 22:52:45 +0100...
> >...and Mario Klebsch <[EMAIL PROTECTED]> wrote:
> >> [EMAIL PROTECTED] (Matthias Warkus) writes:
> >>
> >> >> The problem with Pascal, as distinct from the others, is that the
> >> >> design just wasn't made for anything more than education.
> >> >...
> >> >e) No pointers to functions AFAIK
> >>
> >> At least they were possible as arguments to function/procedure
> >> calls. I am not sure, wether they are possible as stand alone
> >> variables or as structure members. However, there were a lot pascal
> >> compilers in use, that did not implement procedure arguments.
> >
> >If pointers to functions exist, then there's another e):
> >
> >e) No variable length argument lists for you.
>
> Well, C didn't have these either, initially. People did it anyway, as a a
> complete platform specific hack, relying on the lack of type checking in C and
> the local stack layout. Andrew Koenig introduced <varargs.h> but it was not
> until ANSI C that we got the ellipsis punctuator and <stdarg.h>.
I don't care about history. What's important for me is that this is in
ANSI C, while it's not in ANSI Pascal.
mawa
--
Knieschutzskater!
Kommunalw�hler!
Komplettl�sungsspieler!
Klarsichtumh�ller!
------------------------------
** 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 (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
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
******************************
