Linux-Development-Sys Digest #726, Volume #8 Wed, 16 May 01 20:13:12 EDT
Contents:
Re: Meaning of kernel: NET: 3 messages suppressed (Grant Edwards)
Re: Kernel 2.4.4 and Adaptec 1480 Slim SCSI Desperate HELP Please. David Hinds?
("E-mu")
Re: Loading modules permanently (Heinz Ruffieux)
Re: Why O_SYNC and fsync are slow on Linux? (Greg Copeland)
Re: Will Linux recognize >4GB RAM on Pentium-III Xeon? (Greg Copeland)
Re: SIGSEGV is not blocking ("Michael J. Saletnik")
Re: Loading modules permanently
Help me write a driver (Curtis Russell Nielson)
Re: SIGSEGV is not blocking
creating files under /proc? (Timur Tabi)
Re: SIGSEGV is not blocking (David Schwartz)
Re: Formulating Compatibility Signature: (Bernd Strieder)
Re: SIGSEGV is not blocking (Linus Torvalds)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: Meaning of kernel: NET: 3 messages suppressed
Date: Wed, 16 May 2001 20:29:30 GMT
In article <[EMAIL PROTECTED]>, Frank Sweetser wrote:
>Grant Edwards <[EMAIL PROTECTED]> wrote:
>>I've asked in comp.os.linux.networking, but either nobody
>>knows, or they don't want to answer. :(
>
>This is the kernel suppressing duplicate messages. Can't really
>do anything with the messages, though, since all you have here is
>the supression messages - we'd need the actual message itself.
Aargh...
I should know by now not to pay attention comments. A comment
the ratelimit() source code said all warning messages should be
guarded. After looking through the network sources, I finally
noticed that some of the printk() calls guarded by
net_ratelimit() were debug level. After enabling kernel.debug
messages I finally see the "suppressed" messages:
May 16 15:25:41 grante kernel: protocol fe11 is buggy, dev eth1
May 16 15:25:41 grante kernel: protocol fe11 is buggy, dev eth1
May 16 15:25:44 grante kernel: NET: 78 messages suppressed.
May 16 15:25:44 grante kernel: protocol fe11 is buggy, dev eth1
May 16 15:25:49 grante kernel: NET: 124 messages suppressed.
May 16 15:25:49 grante kernel: protocol fe11 is buggy, dev eth1
May 16 15:25:54 grante kernel: NET: 124 messages suppressed.
May 16 15:25:54 grante kernel: protocol fe11 is buggy, dev eth1
May 16 15:25:59 grante kernel: NET: 95 messages suppressed.
May 16 15:25:59 grante kernel: protocol fe11 is buggy, dev eth1
May 16 15:26:31 grante kernel: NET: 5 messages suppressed.
--
Grant Edwards grante Yow! Yow! Am I cleansed
at yet?!
visi.com
------------------------------
From: "E-mu" <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.4.4 and Adaptec 1480 Slim SCSI Desperate HELP Please. David
Hinds?
Date: 16 May 2001 21:11:20 GMT
It works if I choose aic7xxx as (m) rather than driver into the kernel.
But shouldn't it work as (y) in "make menuconfig" as well?
"E-mu" <[EMAIL PROTECTED]> wrote in message
news:9dru64$[EMAIL PROTECTED]...
> I was told by Alan Cox that the driver for the apa_1480 Adaptec Slim Scsi
> was intentionally left out because the new driver for aic7xxx in this
kernel
> 2.4.4 will handle the aha_1480 cardbus card.
>
> Well, I am having problems when the kernel boots up. Here is what I can
get
> from it thus far.
>
>
> Here is the error I get during the boot up of the kernel. Maybe you can
> tell me what to do?
>
> QoutPOS = 210
> ahc_pci:2:0:0: Warning no command for scb0 (cmdcmptl)
> QoutPOS = 211
> ahc_pci:2:0:0: Warning no command for scb0 (cmdcmptl)
> QoutPOS = 212
> ahc_pci:2:0:0: Warning no command for scb0 (cmdcmptl)
> QoutPOS = 213
> ahc_pci:2:0:0: Warning no command for scb0 (cmdcmptl)
>
> etc etc
>
> This loops about 100 or more times
>
> Then this happens:
>
> QOUTPOS = -1
> ahc_pci:2:0:0 Someone reset channel A
> Unable to handle Kernel NULL pointer dereference at virtual address
00000000
> printing eip:
> c02727f6
> *pde=00000000
> Oops:0000
> Cpu: 0010:[<c02727f6>]
> Eflags: 0001000096
> eax: 00000041
>
> etc etc etc followed by a STACK DUMP, which I could not copy all that
> information down!
>
>
> Then this happens:
>
> Kernel Panic : Aiee, Killing interrupt handler!
> In interrupt handler-not syncing
>
> Can you halep me on this or point me to someone who can help me figure out
> what is the deal here?
>
> I was told by Alan Cox that I may have to make some changes in my PCMCIA
> config file BUT, the config file is not bring accessed at this point
during
> the Kernel Boot phase. Or at least I think its not?
>
> My kernel is completly monolithic except the Firewire driver. Previous
> kernels had the aha_1480 driver in SCSI section under PCMCIA. There was a
> choice for it specifically and it could only be chosen as module. This
> allways worked fine for me, until they removed it from kernel 2.4.4, since
> it suppose to be handled by the new aic7xxx diver tree. I wonder about
that
> though?
>
> Thanks for you patience :):)
>
>
------------------------------
From: Heinz Ruffieux <[EMAIL PROTECTED]>
Subject: Re: Loading modules permanently
Date: Wed, 16 May 2001 21:30:05 -0000
Kasper,
Thanks a lot for your support. In your statement I read, that there is NO
other way to load modules that adding the modprobe <module> command in
/etc/modules.conf - right? I thougt, that there is an other way. This was
confusing me.
Thanks
Heinz
Kasper Dupont wrote:
>
> Heinz Ruffieux wrote:
> >
> > Thanks Karl for your help.
> >
> > I tried modprobe several times, but unfortunatly after a reboot the
desired
> > modules do not get loaded. Do I need to add something to
/etc/modules.conf?
> >
> > Could you please state an example (e.g. with msdos)?
> >
> > Thanks a lot
> >
> > Heinz
>
> Did you write "modprobe msdos" on the command line?
> You have to write it into the file /etc/rc.d/rc.local.
>
> If it still doesn't work see if it prints any error
> messages at startup and also look through the last
> few lines of /var/log/messages.
>
> --
> Kasper Dupont
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
Subject: Re: Why O_SYNC and fsync are slow on Linux?
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 16 May 2001 17:25:51 -0500
"Heikki Tuuri" <[EMAIL PROTECTED]> writes:
> Hi!
>
> On different systems I have measured strange differences in performance
> depending
> on whether I open a file with O_SYNC and let the operating system do the
> flushing
> of the file to disk after each write, or if I open without O_SYNC, and call
> fsync myself.
There are so many factors here. They range from implementation detail to the
hardware that is supporting the implementation. Remember, some disks have
very large caches and can be configured for write-back caching. Also, SCSI
disks with a good controller tend to do better on things like this because
the OS can issue tagged writes which means that the controller/disk is not
only caching but performing gathered writes as well. This is one area that
IDE generally falls short on, unless it, again, it has write-back caching,
which can sku the expected results in a slightly different manner.
> On Windows NT I have not noticed such performance problems if I use
> non-buffered
> i/o to a file.
You can't really compare OS's because they can be implemented completely
different, especially if different hardware is in the mix. One thing that
is for sure, in almost all cases (that is, as a rule of thumb), you should
always see a negative performance impact when using non-buffered I/O. The
reasons for this are obvious. If you are not seeing some type of delta, it
implies that you are not performing a metric with enough accuracy to measure
a delta for your OS/hardware combination. It's important to remember that
some drives may have 2M+ worth of cache, which *may* be used as a write-back
cache. If that's the case, if you are writing less than 2M at a time and
allowing for the cache to be written prior to attempting a second write,
your write operations will seem very fast. In these cases, even though the
intention is to make every write a physical write, it's very possible that
they are actually virtual writes, even at the hardware level. If you are
on higher end hardware, you may be looking at large caches on both the
drives and/or the disk controllers, which may have 32M to 2G worth of cache.
Let's not forget solid state drives too...but I'm guessing that this is not
that case here.
>
> I have written a database engine InnoDB under MySQL and bumped into these
> problems
> on Linux.
I think I missed something. I know that you said that you are seeing performance
differences on different platforms, but I guess I don't understand the "problems"
that you are see. What again is the "problem."
--
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
==================================================
------------------------------
Crossposted-To: comp.os.linux.hardware
Subject: Re: Will Linux recognize >4GB RAM on Pentium-III Xeon?
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 16 May 2001 17:29:33 -0500
Linux can access up to 4G of process space per process, however, if
you CPU supports PAE and the kernel is compiled to support it, you
can access up to 64G with 4G per process, as is my understanding.
I *think* that most pentium-pro on up processors support PAE modes.
There is another recent thread around there which talks about this
a little.
Greg
[EMAIL PROTECTED] (Doug Chan) writes:
> Thanks!
> I read somewhere that the process address space is still limited to
> less than 4GB?
>
> -Doug
>
> In article <[EMAIL PROTECTED]>,
> reader of news <[EMAIL PROTECTED]> wrote:
> >2.4 kernel can handle up to 64gb.
> >just have to turn it on during compilation.
> >don't know whether it will for your xeon
> >
> >On Tue, 15 May 2001 18:57:36 GMT, Doug Chan <[EMAIL PROTECTED]> wrote:
> >>I know that the Pentium-III Xeon supports 36-bit addression (up to 64Gb)
> >>of RAM however it required that the OS knows about this "pse-36" mode
> >>for this extended memory support.
> >>Does Linux support this extended memory mode?
> >>
> >>Thanks,
> >>-Doug
> >>apollo at world.std.com
>
>
--
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
==================================================
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
From: "Michael J. Saletnik" <[EMAIL PROTECTED]>
Date: Wed, 16 May 2001 22:32:28 GMT
David Schwartz <[EMAIL PROTECTED]> writes:
> You say it ought to "work". What do you mean? What behavior would
> constitute working? You have left no reasonable thing for the
> implementation to do.
If I explicitly block the SIGSEGV from being delivered, I would not
expect the process still to terminate on a SIGSEGV.
For example, in the example code shown it *is* perfectly acceptable to
continue down the codeline since we don't do anything with the null
value that we've tried to dereference and faulted on.
In other scenarios I might just keep SIGSEGV'ing until
unblocked/pending-delivered or it died for another reason.
What bothers me is that SIGSEGV was blocked, and yet still
delivered, and I want to know why. Was the block flat-out ignored, or
did something else clear the block and the pending signal was
delivered?
I understand that "behavior is unspecified" but would not expect that
be what the programmer has explicitly asked to *not* have happen.
--
{michael}
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Loading modules permanently
Date: Wed, 16 May 2001 22:38:44 -0000
In article <[EMAIL PROTECTED]>,
Heinz Ruffieux <[EMAIL PROTECTED]> wrote:
>Thanks a lot for your support. In your statement I read, that there is NO
>other way to load modules that adding the modprobe <module> command in
>/etc/modules.conf - right? I thougt, that there is an other way. This was
>confusing me.
No, you add the modprobe command to /etc/rc.d/rc.local. You could also
compile a kernel with what you want compiled in instead of being a loadable
module.
--
http://www.spinics.net/linux
------------------------------
From: Curtis Russell Nielson <[EMAIL PROTECTED]>
Subject: Help me write a driver
Date: Wed, 16 May 2001 16:24:17 -0600
I am trying to write a very simple Kernel Loadable device driver for a
character device and I built. The card is a very simple 8255 PPI. I
am not very familiar with any kind of kernel programming and would
appreciate some instructions or example code I could look at. Thanks in
Advance
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Wed, 16 May 2001 22:46:20 -0000
In article <[EMAIL PROTECTED]>,
Michael J. Saletnik <[EMAIL PROTECTED]> wrote:
>> You say it ought to "work". What do you mean? What behavior would
>> constitute working? You have left no reasonable thing for the
>> implementation to do.
>If I explicitly block the SIGSEGV from being delivered, I would not
>expect the process still to terminate on a SIGSEGV.
Then what will it do when it faults?
>For example, in the example code shown it *is* perfectly acceptable to
>continue down the codeline since we don't do anything with the null
>value that we've tried to dereference and faulted on.
But what state is the processor in after the trap? With pipelined
execution continuing on might not even be possible. You should fix
your code instead.
--
http://www.spinics.net/linux
------------------------------
From: Timur Tabi <[EMAIL PROTECTED]>
Subject: creating files under /proc?
Date: Wed, 16 May 2001 18:16:55 -0500
I have a driver which creates a directory and a couple files under
/proc, namely /proc/zfc/. Is it possible to create new files in
/proc/zfc/ using the ln, cat, or cp commands? I can't seem to find any
examples of doing that, so I'm not sure whether it can be done (or where
to look to find out).
--
Timur Tabi
Remove "nospam_" from email address before sending reply
Interactive Silicon - http://www.interactivesi.com
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Wed, 16 May 2001 16:19:27 -0700
"Michael J. Saletnik" wrote:
> If I explicitly block the SIGSEGV from being delivered, I would not
> expect the process still to terminate on a SIGSEGV.
What do you expect? There's nothing reasonable that's possible.
> For example, in the example code shown it *is* perfectly acceptable to
> continue down the codeline since we don't do anything with the null
> value that we've tried to dereference and faulted on.
No, it is *impossible* to continue down the codeline. The operating
system has no way to know how much code should be 'skipped' or whatever.
> In other scenarios I might just keep SIGSEGV'ing until
> unblocked/pending-delivered or it died for another reason.
That doesn't make sense.
> What bothers me is that SIGSEGV was blocked, and yet still
> delivered, and I want to know why. Was the block flat-out ignored, or
> did something else clear the block and the pending signal was
> delivered?
Please give me one reasonable example of what could happen. The only
one I can think of is an endless spin, generating a SIGSEGV (which is
blocked) and then restarting the blocked operation.
> I understand that "behavior is unspecified" but would not expect that
> be what the programmer has explicitly asked to *not* have happen.
There is no such thing as explicitly asking for something while at the
same time invoking undefined behavior.
DS
------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Re: Formulating Compatibility Signature:
Date: Thu, 17 May 2001 01:40:12 +0200
Adam Shapira wrote:
>
> Generally, with my programs, the installer uses two variables,
> OS_TYPE and HOSTTYPE, to determine if the pre-compiled object
> files are compatible with the current machine that I'm trying
> to install a program on.
Those variables are set in scripts under /etc or elsewhere. Every distro
has different ones. The "uname" app uses the uname (2) syscall to get
its information from the kernel. Not that it would be impossible to
fiddle around with it, but this won't happen. The problem is, that it
does not give enough information. See below.
> Is there any more official way of determining a compatibility
> signature other than using the OS_TYPE and HOSTTYPE environment
> variables?
Why are there different RPMs for the different distros like Redhat,
SuSE, etc? Why are there even different RPMs for particular releases of
each distro? In general you couldn't produce one binary running on all
distros and all releases, even if you had that clever signature. Produce
as much packages as needed to get it running where needed.
In the case you dynamically link C++, you have to build a package for
nearly every single release. The C++ ABI is not yet finished, i.e.
changed quite often.
If you linked statically, there would be less different packages needed,
but at some runtime cost.
What does your app depend on? Where is it provided? These are the key
questions. Identifying the system is rather useless.
You have touched a problem that is a pain in everybodies a... Many years
of FHS battles, rivalities between the package systems have not yet
stopped. Everything has to be duplicated many times for in essence very
minor differences. Most of the users don't care, they are happy with one
running system, but the people providing parts of the system, they pay
many times for it. And often enough the users are confused as well in
the case, a package doesn't install or work. To be fair, it's difficult
enough to produce one collection of packages making a working system.
Making the packages widely interchangable is just considered unrealistic
in practice.
Bernd Strieder
------------------------------
From: [EMAIL PROTECTED] (Linus Torvalds)
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: 16 May 2001 17:04:37 -0700
In article <[EMAIL PROTECTED]>,
Michael J. Saletnik <[EMAIL PROTECTED]> wrote:
>
>If I explicitly block the SIGSEGV from being delivered, I would not
>expect the process still to terminate on a SIGSEGV.
Well, the kernel has no alternative. It has to do something. You told it
not to send the SEGV, so _what_ do you expect it to do?
What Linux will do (an dyou should expect other UNIXes to do the same,
AIX notwithstanding), is to say "if we generate a fault that we can't
just continue on, and the fault is blocked, we just ignore that anyway".
Reasonable, no?
>For example, in the example code shown it *is* perfectly acceptable to
>continue down the codeline since we don't do anything with the null
>value that we've tried to dereference and faulted on.
It is NOT POSSIBLE!
If the kernel just returns, the process will take the same fault over
and over and over again. The fault is not going away. The CPU does not
advance the instruction pointer past the instruction that faulted, and
the kernel is sure as hell not going to try to decode the instruction to
see what it should do.
>In other scenarios I might just keep SIGSEGV'ing until
>unblocked/pending-delivered or it died for another reason.
It's never ever going to be unblocked. The process will never make any
progress, and thus the process will never even have the _possibility_ of
unblocking the signal.
>What bothers me is that SIGSEGV was blocked, and yet still
>delivered, and I want to know why.
Because the kernel had two choices: deliver it despite the programmer
telling it not to, or killing the process outright because the process
is no longer doing anything useful.
Now, you might say that killing is better. I might agree. We can vote on
it, I don't personally particularly care one way or the other. But you
only get those two choices: kill the dang thing outright, or just ignore
the blocking. We just don't have any other good choices.
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
******************************
