Linux-Development-Sys Digest #857, Volume #7 Mon, 15 May 00 10:13:17 EDT
Contents:
Kernel panic: aic7xxx: unrecoverable BRKADRINT. In swapper task - not syncing.
("Reinhold J. Gerharz" >)
Re: LILO Win+Linux on an old system (Josef Moellers)
Re: Need input on developing a unified configuration program for linux
("AnonymousCoward")
Re: Gettimeofday ("Reinhold J. Gerharz" >)
creation of global variables in kernelmodules ("Michael Palme")
Re: ANSI C & void main() (Erik Max Francis)
Re: ANSI C & void main() (Erik Max Francis)
Re: ANSI C & void main() (Erik Max Francis)
Re: ANSI C & void main() (Erik Max Francis)
Re: es1371 modules problem (Josef Moellers)
Re: process structure ([EMAIL PROTECTED])
Re: Kernel panic: aic7xxx: unrecoverable BRKADRINT. In swapper task - not syncing.
([EMAIL PROTECTED])
Adaptec DuraLAN (ANA-62022/starfire) card on Linux 2.2.xx? (Josef Moellers)
Re: Need input on developing a unified configuration program for linux (David A.
Lethe)
Re: ANSI C & void main() (Matthew Palmer)
----------------------------------------------------------------------------
From: "Reinhold J. Gerharz" <PostNoEmail <[EMAIL PROTECTED]>>
Crossposted-To: linux.redhat.install
Subject: Kernel panic: aic7xxx: unrecoverable BRKADRINT. In swapper task - not syncing.
Date: Mon, 15 May 2000 01:14:08 -0400
> The above is the error I get on the first screen when trying to install
Red
> Hat Linux 6.2
>
> Any ideas what it means?
>
> Thanks!
PS. Oops! Forgot to mention: Its on an EISA 486 PC with AHA-2742, ATI Ultra
Graphics Pro, and slot 4 is vacant. The PC just locks up!
PPS. RH Linux 6.1 installed just fine...
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: LILO Win+Linux on an old system
Date: Mon, 15 May 2000 09:03:34 +0200
"Paul D. Smith" wrote:
> =
> %% Josef Moellers <[EMAIL PROTECTED]> writes:
> =
> Josef: thanks for your time on this.
No sweat. Experience shows that tomorrow a customer will call with
exactly the same problem ... B-{)
> You mentioned in your message that the cylinder value is useless; can
> that be right, when the only difference in geometry between my 1G and 2=
G
> HD that BIOS reports is in the cylinder value?
The "cylinders" value is not "useless", but it's irrelevant to a degree.
Modern disks do not have a physical layout that's strictly "spt
sectors/track" everywhere, but they store more sectors on the outer
tracks and less sectors on the inner tracks, wich makes sense, if you
think about it. SCSI does not have the notion of a
"cylinder/head/sector" address but uses linear addresses, but IDE disks,
which have to be compatible, have to provide this interface.
Therefore a "logical" layout of a fixed number of sectors/track for each
and every track is used which apparently can be taylored to your needs.
I don't know the technicalities myself, but I guess that e.g. there are
BIOSes that allow only 63 heads while there are BIOSes that allow 255
heads, so a means must be provided to taylor the disk's logical layout
to the needs of the BIOS. My IBM disks at home have a jumper than can be
used to select between two layouts.
Anyway, if you just number the sectors from 0 to (n-1), where n is the
total number of sectors on the disk, then, given "spt" as the "logical
number of sectors/track", "hed" which is the "logical number of heads",
and the fact that tracks are filled first, then cylinders, the cylinder,
head and sector numbers of a given linear sector can be calculated as
follows (I hope you can C B-{):
sector =3D linear % spt;
head =3D (linear / spt) % hed;
cylinder =3D linear / (spt * hed);
vice versa:
linear =3D (cylinder * hed + head) * spt + sector;
As you can see, the total number of cylinders your disk has is not used
in these calculations. It can, however, be used to check that the
cylinder you have calculated is less than the number of cylinders your
disk has.
> =
> I'm at a loss...
Hm, let's get back to your original setup and leave the floppy where
it's supposed to be: in the box. I still believe that the "linear"
option should solve your problems ...
I have a similar setup at home, although Linux goes first (/dev/hda)
with an NDOS/WfWG payload and W98 goes second (/dev/hdb). I'll get the
lilo.conf and send them tomorrow (if I don't forget). I'm at work now
and don't have access to my machine at home. Here at work I have Linux
only while the colleagues have NT only, no mixed installs.
Stay tuned ...
-- =
Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1
------------------------------
From: "AnonymousCoward" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Need input on developing a unified configuration program for linux
Date: Mon, 15 May 2000 03:32:34 -0400
> HTML is absolutely the way to go.
>
> However ...
> What happens if you want to change the IP number of your linux box?!!
>
Changing your box's IP is not a problem, because you would be using the
loopback IP, not your box's internet IP. 127.0.0.1 will always get the
current machine.
------------------------------
From: "Reinhold J. Gerharz" <PostNoEmail <[EMAIL PROTECTED]>>
Subject: Re: Gettimeofday
Date: Mon, 15 May 2000 03:43:23 -0400
"pramodh mallipatna" <[EMAIL PROTECTED]> wrote in message
news:8fkika$bdn$[EMAIL PROTECTED]...
> Hi,
>
> I have a problem with gettimeofday().
> I do something like this.
>
> gettimeofday(&startTime, &tz);
>
> do_stuff();
>
> gettimeofday(&endTime, &tz);
>
> When I take the difference between endTime and startTime, I normally
> get correct results...but sometimes, startTime is greater than endTime and
> hence I get negative time difference...
>
> do_stuff() takes non-zero amount of time...I even tried this stopping my
> xntpd so as to rule out its effect. But still, I have the problem.
>
> Any suggestions about what is happening?
>
> Thanks,
> Pramodh
I wonder what processor and kernel version you are using. I know that kernel
2.0 and before do not work correctly when reading times within the same
Jiffy (or clock tick) on i486 or i386 systems. Pentiums use a different
device for measuring time.
Please see this link for a possible fix using a 64 bit timer module:
http://www.cyberspace.org/~rgerharz/Linux/index.html
------------------------------
From: "Michael Palme" <[EMAIL PROTECTED]>
Subject: creation of global variables in kernelmodules
Date: Mon, 15 May 2000 09:45:44 +0200
/*
Hello.... !!!!
I want to create some global variables
inside a kernelmodule. Whats the best way do do
that ??
*/
/****************types for the vars**************/
typedef struct _ANYTYPE {
.
.
.
stuff;
more_stuff;
struct {
.
.
lots_of_stuff;
.
.
} thing;
and_so_on;
.
} ANYTYPE, *PANYTYPE;
typedef struct _ANYTYPE1 {
.
.
like_above;
.
.
} ANYTYPE1, *PANYTYPE1;
/**********************Variant1************************/
static PANYTYPE ptr_anyvar;
static PANYTYPE1 ptr_anyvar1;
int init_module(void) {
ptr_anyvar = kmalloc(sizeof(ANYTYPE), GFP_KERNEL);
if(!ptr_anyvar) return -ENOMEM;
memset(ptr_anyvar, 0, sizeof(ANYTYPE);
ptr_anyvar1 = kmalloc(sizeof(ANYTYPE1), GFP_KERNEL);
if(!ptr_anyvar1) return -ENOMEM;
memset(ptr_anyvar1, 0, sizeof(ANYTYPE1);
return 0;
}
void cleanup_module(void) {
kfree(ptr_anyvar);
kfree(ptr_anyvar1);
}
/**********************Variant2************************/
static ANYTYPE anyvar, *ptr_anyvar;
static ANYTYPE1 anyvar1, *ptr_anyvar1;
int init_module(void) {
ptr_anyvar = &anyvar;
ptr_anyvar1= &anyvar1;
return 0;
}
void cleanup_module(void) {
}
/*
Which of the variants is better ???
Is there another way ??
In the variant2 is the allocated memory
automatically cleaned after creation of
the variables?
Is the memory for the variables
freed at ,rmmod' (in variant2)??
What happens in variant2 if there is an
error by creating of the variables
(not enough memory or something like this)?
Can I use memcpy() in kernelmode to copy
some memory from one location in kernelspace
to another (in kernelspace).
Thanks....Michael Palme
*/
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Sun, 14 May 2000 10:52:52 -0700
Frank wrote:
> Actually main() isn't returning an 'int', exit(0) is being called
> instead.
That makes no difference. The prototype for main is important for _it
to be called at all_, whether or not it "really" returns something. The
Standard was quoted. It made it painfully clear that main "shall"
return int. _Shall_ is a term defined by the Standard to mean "must."
No, the Standard doesn't explicitly say that main cannot return void.
But it says that it _must_ return int. So returning void is illegal.
It doesn't explicitly say that main can't be defined as taking two
cucumbers and returning an orange either. But stating that the Standard
admits that in a compliant program would be downright silly. That's
what you seem to be doing; the Standard was very clear on the subject,
but you seem to be ignoring the very Standard that you're trying to
claim supports you.
> I'm going to have to back out of this discussion because I don't have
> the
> necessary documentation, but I will leave by quoting an old manual
> that I do
> have available.
Which is totally and utterly irrelevant. (Which you seemed to know, but
still quoted it anyway.)
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ The public is a fool.
\__/ Alexander Pope
Crank Dot Net / http://www.crank.net/
Cranks, crackpots, kooks, & loons on the Net.
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Sun, 14 May 2000 12:41:38 -0700
Mike McDonald wrote:
> Except main() never returns. In the context of main(), the return
> statement
> has the same effect as calling exit(). Reaching the end of main() is
> the same as
> executing "return 0;", which is effectively "exit(0);". So talking
> about the
> "return type" of main() seems kind of waste.
The return type of main is quite relevant, because the startup code must
figure how to call it. In any event, the return value of main can be
used by the operating system, and having the wrong prototype for main
can result in that return value, which is expected to be in a certain
register or memory location, not being present, which can cause
problems. It's a function. It has a return type. The Standards
indicate what that return type must be. So talking about main's return
type is hardly a waste.
Besides, as Kaz pointed out (and as does the comp.lang.c FAQ, as I
recall), exit is _not_ precisely the same as returning from main. It's
close, but not quite
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ The quickest way of ending a war is to lose it.
\__/ George Orwell
Fat Boy and Little Man / http://www.fatboyandlittleman.com/
Watch Fat Boy and Little Man go about their antics.
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Sun, 14 May 2000 22:03:48 -0700
Mark Graybill wrote:
> Erik Max Francis wrote in message <[EMAIL PROTECTED]>...
>
> >No. You are not reading it right.
> >
> > "It shall have a return type of int ..."
> >
> >main must return int. Period.
>
> No, there wasn't a period, there was a ", but otherwise."
So what? You are really grasping at bizarre straws here. The Standard
is very clear.
> You have this flipped. A function's type and it's argument list are
> two
> separate things.
You _must_ be trolling.
Read the Standard. Read the FAQs. Tone down your ego. You're mistaken
on this, no matter how much you try to twist the very clear words of the
Standard.
> It takes some twisting to read it the way you do. I will admit I am
> reading
> this incorrectly if the reply from ANSI states so, and I will openly
> publish
> my error.
Bizarre.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Procrastination is the thief of time.
\__/ Edward Young
Crank Dot Net / http://www.crank.net/
Cranks, crackpots, kooks, & loons on the Net.
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: Sun, 14 May 2000 21:58:17 -0700
Mark Graybill wrote:
> Hmm. I never heard of "standardese." I will check with ANSI, ISO,
> OMB,
> IEEE, and a couple of others to see if I can learn "standardese."
> Perhaps
> they will have seminars and courses available. Poppycock! There is
> no such
> thing. I think it is you who are desperate (although I don't know
> why), and
> you have a problem with being wrong.
The C and C++ Standards both start by very specifically and deliberately
indicating what terms used within them mean. You don't seem to
understand these terms as the Standards use them.
> The standard is written in English. There is no prohibition of the
> type of
> void for main(), and the behavior of any type that does not return a
> value
> is clearly defined. It is as clear as the English language has
> ability to
> articulate.
Then you must not understand English.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Procrastination is the thief of time.
\__/ Edward Young
Crank Dot Net / http://www.crank.net/
Cranks, crackpots, kooks, & loons on the Net.
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: es1371 modules problem
Date: Mon, 15 May 2000 10:17:09 +0200
David Ronis wrote:
[ ... ]
> Other loadable modules load and unload automatically as expected. I'm
> probably missing something in the modules.conf file.
Try
alias char-major-14 es1371
-- =
Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: process structure
Date: 15 May 2000 00:59:12 -0700
In article <8fnpf0$1kao$[EMAIL PROTECTED]>, "flybird" says...
>
>hi,all
> I am interesting in process structure. I noly have study elf format
>through elf.ps but don't understand it too much. I hope to get more paper
>about elf to study. And I would like to know how linux process is
>implemented according elf.
To learn linux process structure, see the file
/usr/src/linux/inlcude/linux/sched.h, look for task_struct.
I do not know what you mean by "know how linux process is implemented
according elf". elf is the format of the linux binary file, such is
the '/a.out'. Or are you talking about needing to know the
layout of the virtual address space for a linux process?
>I also would like to know how the process structure is implemnted
>on the i386 sturcutre, especially how the linux use the segment selector of
>i386.
>May someone point me some good paper about these question of the web?
It is implemented the same, as a C struct. see task_struct above.
When linux boots, it boots in real 16 bit mode, then in
usr/src/linux/arch/i386/boot/bootsect.S it eventually switches the
processor to 32 bit protected mode. Linux runs in protected mode from
then on.
So you can look at the above file to see how it uses the di, and si
registers.
hope this helps.
Nasser
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: linux.redhat.install
Subject: Re: Kernel panic: aic7xxx: unrecoverable BRKADRINT. In swapper task - not
syncing.
Date: 15 May 2000 01:10:27 -0700
In article <[EMAIL PROTECTED]>, "Reinhold says...
>
>The above is the error I get on the first screen when trying to install Red
>Hat Linux 6.2
>
It means you have something seriously wrong :)
The above error seems to come from the SCSI controller interrupt handler,
in the aic7xxx device driver. I suggest you contact rhat about this. they
should be able to give you reason why it shows up. could be wrong driver sw,
bad kernel build, HW problems, etc.. do not know.
Nasser
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Adaptec DuraLAN (ANA-62022/starfire) card on Linux 2.2.xx?
Date: Mon, 15 May 2000 10:57:24 +0200
Hi,
Has anyone tried to port the 2.3.99pre6 starfire driver to a 2.2.xx
kernel?
I'm about to do so but don't want to waste resources.
-- =
Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1
------------------------------
From: [EMAIL PROTECTED] (David A. Lethe)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Need input on developing a unified configuration program for linux
Date: Mon, 15 May 2000 12:25:07 GMT
On Mon, 15 May 2000 03:32:34 -0400, "AnonymousCoward"
<[EMAIL PROTECTED]> wrote:
>> HTML is absolutely the way to go.
>>
>> However ...
>> What happens if you want to change the IP number of your linux box?!!
>>
>
>Changing your box's IP is not a problem, because you would be using the
>loopback IP, not your box's internet IP. 127.0.0.1 will always get the
>current machine.
>
>
Sure, it would be safe if you never wanted to do remote configuration.
After re-reading the initial post, the author never mentioned remote
configuration, so it should be fine.
------------------------------
From: [EMAIL PROTECTED] (Matthew Palmer)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: 15 May 2000 20:51:02 +1000
Mark Graybill is of the opinion:
>No, there wasn't a period, there was a ", but otherwise."
>
>> "... but otherwise its type is implementation-defined."
>>
>>But main's argument list can be implementation-defined. That is, an
>>ANSI-compliant C++ compiler must accept int main(void) and int main(int
>>argc, char *argv[]). It can also accept other argument lists, _but it
>>must return int_. This was clearly and explicitly stated by the
>>Standard, but you missed it.
>
>You have this flipped. A function's type and it's argument list are two
>separate things.
Erm, no they're not. A function's type is comprised both of it's return
type and it's argument type list. This is easily seen from the declaration
of a function pointer:
void (*f1)(int);
void (*f2)(void);
An attempt to assign the value of f1 to f2 provides a compiler diagnostic on
my system (Linux 2.0.36, glibc 2.1.3, gcc 2.95.2 20000220 (Debian)) and
while you may make a point-scoring exercise of the fact that 'gcc doesn't
define the standard' I think that it's generally considered to be fairly
accurate.
If that doesn't convince you, consider how C implementations pass variables
to functions. Via the stack. Now, if I had successfully assigned f1 to f2
in my program, and then called f2(), it would have passed no parameters on
the stack. However, when the function began to execute, it would think that
it had an argument to pull off the stack (because f1() takes one int
argument) trashing the stack and making life rather untenable for all time
to come.
>The "shall" is used instead of "must". Much could be read into this, and
'shall' means 'must' in terms of the standard. I think this is defined standard
somewhere.
>Look at the sentence again:
OK.
>"It shall have a return type of type int, but otherwise its type is
>implementation�defined. All implementations
>shall allow both of the following definitions of main: int main() { /* ...
>*/ } and int main(int argc, char* argv[]) { /* ... */ }"
>
>The but otherwise provides the exception to the return type of int. An
If you insist that the type of a function is only based on it's return type,
then yes. However, taking 'shall' to mean 'must' (which someone else
(I think it was Kaz) showed was the case) and that the type of a function is
defined by it's return type AND it's argument list (which I showed above is
almost certainly the case) then you're interpretation is flawed.
>implementation (compiler) can choose other types of main. It does not
>prohibit non-int types. I fail to understand why you cannot see this. If I
The standard eoss prohibit other types for the return type of main. "It
SHALL (read must) have a return type of int".
I would appreciate, BTW, if someone would dig up the reference from the
standard which defines what 'shall' means in terms of the standard.
>say the sky is blue, but otherwise it is a different color, doesn't say it
>can only be blue.
Yes, but you didn't use 'shall' or 'must' or even 'should'. Saying 'the sky
is blue' can easily be taken as a statement of opinion - which, as an aside,
it is. It's a matter of perception (and not wantint to get into a
philosophical ramble, but you should look up "Mad Pain and Martian Pain" by,
damn, can't remember the author) rather than incontrovertable fact, and is
based around a common set of definitions of the 'blueness' of something.
Hang on, I'm arguing in the wrong direction here - I've just opened the door
for someone to argue on the basis of the 'int'ness of something. Argh. <g>
>>This is a red herring.
Or a blue herring, depending on your point of view. Or maybe a char**
herring...
Argh, I've lost the plot. Focus Matthew, focus... <g>
>>stated earlier -- namely, that main must return int. (Besides, a return
>>0, implicit or not, at the end of a function which returns void is
>>illegal -- another hint that you're reading this wrong.)
>
>You can have a return statement without a value. I'm not interested in
Yes, but you can't have a return with a value in a function returning void.
For instance,
void foo(void)
{
return 0;
}
should produce a diagnostic along the lines of "return with a vlaue in a
function returning void". An implicit 'return 0;' at the end of void main()
should produce a similar diagnostic, since the concept holds.
>It takes some twisting to read it the way you do. I will admit I am reading
>this incorrectly if the reply from ANSI states so, and I will openly publish
>my error.
In that case, let's see what ANSI says on it.
You're actually lucky in this argument, that you're not arguing this on
comp.lang.c - you'd be arguing with some of the people who will likely make
up the response from ANSI. <g>
--
=======================================================================
#include <disclaimer.h>
Matthew Palmer
[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 (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
******************************
