Linux-Development-Sys Digest #590, Volume #8 Mon, 26 Mar 01 10:13:10 EST
Contents:
Re: kernel problem (Werner =?iso-8859-1?Q?K=FChnert?=)
Re: USB vend/prod determination (Ulrich Eckhardt)
Re: A couple of newbie questions ("Quiney, Philip [HAL02:HH00:EXCH]")
Re: i am confusing about write.s? (Arne Driescher)
Change in PPP handling from 2.4.0 to 2.4.1? (Birger Toedtmann)
Re: i am confusing about write.s? (Josef Moellers)
Re: core.pid (Michel Bardiaux)
system-assigned groups ("Laurie")
Re: do {.....} while(0); in macro definitions ("Arthur H. Gold")
Re: wipeinfo, secure delete, device driver (Kasper Dupont)
Re: kernel problem (Kasper Dupont)
Re: Process Scheduler/Resource Management (Kasper Dupont)
Re: Process Scheduler/Resource Management (Kasper Dupont)
Question about printk ("jbhuang")
Re: Question about printk (Kasper Dupont)
Re: Change in PPP handling from 2.4.0 to 2.4.1? (Clifford Kite)
----------------------------------------------------------------------------
From: Werner =?iso-8859-1?Q?K=FChnert?= <[EMAIL PROTECTED]>
Subject: Re: kernel problem
Date: Mon, 26 Mar 2001 08:34:30 +0200
Kasper Dupont wrote:
> Your problem has nothing to do with a missing harddisk,
> at this early point during startup there has not been
> made any attempt to access the harddisk.
>
> What you have told has narrowed the posibilites down
> to only one call of do_exit.
>
> The do_exit function must be called from the RESTORE_ALL
> macro in arch/i386/kernel/entry.S. This is used on the
> return path from system calls, exceptions and interrupts.
> The do_exit function is called if the final IRET
> instruction fails.
>
> Assembly code is a little harder to debug, and I don't
> know exactly what are the possible reasons for the IRET
> instruction to fail, but I will think some more about it.
>
> I have one idea of where to get more information about
> what is happening, but I'm not sure if it will tell me
> anything.
>
> In arch/i386/kernel/traps.c change the line:
> regs->eip = fixup;
> into
> printk("fixup: %08X=>%08X regs=%08X
> regs->esp=%08X\n",regs->eip,fixup,regs,regs->esp);
> regs->eip = fixup;
>
> --
> Kasper Dupont
I did that and the output is :
fixup: C0197A11=>C0198784 regs=C01C7FA8 regs->esp=00000010
and then the output as before.
Is there any way to get the symbol table for the actual kernel and do You have a clue
which interrupt function this could be ? Maybe my hardware does something strange.
Regards,
Werner
--
Werner Kuehnert Siemens AG Oesterreich PSE ECT IPN 1
E-Mail: [EMAIL PROTECTED]
------------------------------
From: Ulrich Eckhardt <[EMAIL PROTECTED]>
Subject: Re: USB vend/prod determination
Date: Sun, 25 Mar 2001 11:13:23 +0200
[EMAIL PROTECTED] wrote:
> I am studying how a USB driver gets connected to a particular vend/prod
> ID. I can see where my device is enumerating and the USB stack reads the
> vendor/product ID off of the chip in usb.c:usb_find_drivers. My question
> is, where is the connection between a vendor/product ID and a module. Is
> there a file somewhere with the connection between vendor/product ID's and
> associated drivers? Is each one hard-coded in the module itself? How does
> the linked list (if there is one) of vendor/product ID's and USB drivers
> work. Any suggestions/pointers, will as always, be gratefully appreciated.
>
>
>
As far as I remember, every USB-driver registers itself with the USB-core.
When the latter then finds a new device, it gives the prod/vend info to
each of the dfrivers in turn and the first to reply 'ok' gets the device.
What devices are accepted by a certain driver is defined by the drivers
themselves, usually you have a table that is checked for valid
prod/vendor-ids.
hth
Uli
------------------------------
From: "Quiney, Philip [HAL02:HH00:EXCH]" <[EMAIL PROTECTED]>
Subject: Re: A couple of newbie questions
Date: Mon, 26 Mar 2001 07:54:15 +0100
Rich wrote:
>
> Hi all,
>
> I'm a bit of a newbie when it comes to kernel programming. Currently I'm
> writing a module as a sort of learning experience.
>
> One question I've come upon is this: what is the difference between say a
> variable of type u32 and a variable of type __u32?
>
> I noticed some of the types have these underscores infront of them. If I
> had say:
>
> __u32 underscore = /* some appropriate value */;
> u32 num;
>
> num = underscore;
>
> would this create problems? Or are the types compatible?
>
> Thanks in advance!
>
> Rich.
Hi,
Check out the following link....
http://lxr.linux.no/
This site cross references the Linux kernel source code. You can do an
identifier search for __u32 and see what it is defined as and where it
is referenced.
I tried this for __u32 - it appears to be definined as 'unsigned int' on
the Intel platform - there appears to be a platform specific definition
for each supported architecture.
Regards
Phil Q
--
Phil Quiney CSIP Demonstrator
[EMAIL PROTECTED] Nortel Networks,
Telephone: +44 (0)1279 402363 London Rd, Harlow,
Fax: +44 (0)1279 402885 Essex CM17 9NA,
United Kingdom.
"This message may contain information proprietary to Northern
Telecom so any unauthorised disclosure, copying or distribution
of its contents is strictly prohibited."
------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Re: i am confusing about write.s?
Date: Mon, 26 Mar 2001 09:12:32 +0200
Leo Naboro wrote:
>
> Hi,I am a beginner of linux assemble.i see a sample for
> http://www.linuxassembly.org/linasm-src.html#write
> and have a confuse in it.
> /* write.s */
> .data
> hello:
> .string "hello world\n"
> .text
> .globl _start
> _start:
> movl $SYS_write,%eax // SYS_write = 4
> movl $STDOUT,%ebx // fd = fileno(stdio)
> movl $hello,%ecx // buf = str
> =======================================
> movl $12,%edx // count = 0x6
> =======================================
> int $0x80
>
> movl $SYS_exit,%eax
> xorl %ebx,%ebx
> int $0x80
> ret
>
> why "$12=0x6"? i think it should be thus "$12=0xc",$12 ,does it? but the
> length is 6 of "hello",so it should "movl $6,%edx".
> Thanks!
Well, the source states:
hello:
.string "hello world\n"
So, your string is 12 char long.
BTW, movl $hello,%ecx moves the address of the string defined
at the lable hello: to register ecx (not the string hello itself).
-Arne
------------------------------
From: Birger Toedtmann <[EMAIL PROTECTED]>
Subject: Change in PPP handling from 2.4.0 to 2.4.1?
Date: Mon, 26 Mar 2001 10:23:16 +0200
Hi,
as there wasn't anything visible through search sites, I hope
this is not a "don't bother us again"-question....
I had PPP configured in my 2.4.0. It worked fine with a
modem on /dev/ttyS0 and pppd-2.3.11.
Now I switched to 2.4.1 (also tried 2.4.2, to no avail) and
conquered a strange behaviour:
- /dev/ttyS0 works fine with pppd, modem is dialing,
connect is made
- pppd quits with ioctl(PPPIOCGFLAGS): invalid argument
An ltrace of pppd when activated gives that this happens
as ioctl is working the /dev/ppp device which returns -1,
but I don't see which parameters do cause this.
I am id=0, /dev/ttyS0 and /dev/ppp are 600. Any ideas?
--
Birger T�dtmann
Handwerker f�r eletronische Netzwerke und deren Dienste
00 83 E2 57 EC 60 0B 1C D3 18 AE 2A 40 55 81 22
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: i am confusing about write.s?
Date: Mon, 26 Mar 2001 11:18:37 +0200
Leo Naboro wrote:
> /* write.s */
> .data
> hello:
> .string "hello world\n"
> .text
> .globl _start
> _start:
> movl $SYS_write,%eax // SYS_write =3D 4
> movl $STDOUT,%ebx // fd =3D fileno(stdio)
> movl $hello,%ecx // buf =3D str
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> movl $12,%edx // count =3D 0x6
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> why "$12=3D0x6"? i think it should be thus "$12=3D0xc",$12 ,does it? b=
ut the
> length is 6 of "hello",so it should "movl $6,%edx".
> Thanks!
Since gcc doesn't write these kind of comments, the comments were added
by a human who has made a mistake.
The length of the string "hello, world\n" is 12, so the code looks OK
but the comment is rubbish.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
------------------------------
From: Michel Bardiaux <[EMAIL PROTECTED]>
Subject: Re: core.pid
Date: Mon, 26 Mar 2001 10:21:27 GMT
Kasper Dupont wrote:
>
> Michel Bardiaux wrote:
> >
> > I would like core files to be named from the pid, like core.12345 (yes,
> > I know it can fill my disk!)
> >
> > I have looked in the sources for kernel 2.2.17 and it seems one has to
> > modify binfmt_elf.c and change what is done with variable "corefile".
> >
> > Is there another way that I missed? Or is there a known patch?
> >
> > TIA.
> > --
> > Michel Bardiaux
> > Peaktime Belgium S.A. Rue Margot, 37 B-1457 Nil St Vincent
> > Tel : +32 10 65.44.15 Fax : +32 10 65.44.10
>
> It would probably not be very hard to do so,
> you will have to change the file fs/binfmt_elf.c
>
> In this file you will find the following lines,
> if you change 0 to 1 you will get core files
> named core.comm where comm is the name of the
> program.
>
> memcpy(corefile,"core.",5);
> #if 0
> memcpy(corefile+5,current->comm,sizeof(current->comm));
> #else
> corefile[4] = '\0';
> #endif
>
> You could replace the lines with your own
> prefference, eg.
>
> sprintf(corefile,"core.%d",current->pid);
>
> Before doing anything I suggest you increase
> the buffer for the name a little bit. You
> could replace 6 with 20 in the line
>
> char corefile[6+sizeof(current->comm)];
>
> Notice that making this buffer too small will crash
> the system, the same will happen if the buffer is too
> big for the stack. (There are approx 4KB stack space)
>
> --
> Kasper Dupont
I had already found all that (but thanks anyway). What I wanted to know
was whether there is an official way or official patch to do that. Seems
not...
Greetings.
--
Michel Bardiaux
Peaktime Belgium S.A. Rue Margot, 37 B-1457 Nil St Vincent
Tel : +32 10 65.44.15 Fax : +32 10 65.44.10
------------------------------
From: "Laurie" <[EMAIL PROTECTED]>
Subject: system-assigned groups
Date: Mon, 26 Mar 2001 21:00:11 +1000
Hi folks
I am looking for a description of or explanation of the function/permissions
etc of the system-assigned groups withing Linux. When Linux is installed
there are several curious groups setup by default and I would appreciate
some help in finding information about them. I have searched through the
linuxdoc.org site to no avail and searched high and low elsewhere without
any joy. I know most of them are not to be inhabited by users but I want to
be
able to explain their purpose to students of mine.
Any info or helpful URLs greatly appreciated
Thanks
Laurie
------------------------------
Date: Mon, 26 Mar 2001 02:34:41 -0600
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: Re: do {.....} while(0); in macro definitions
Kiran wrote:
>
> Hi,
> Why do macros coded in the linux kernel usually expand to:
> do {......} while(0);
> form?? why not just :
> {.....} ??
>
> For eg., quoting a code snippet from spinlock.h,
> #define spin_lock_irqsave(lock, flags) do { local_irq_save(flags);\
> spin_lock(lock); } while (0)
>
> could've been
> #define spin_lock_irqsave(lock,flags) {local_irq_save(flags); \
> spin_lock(lock); }
>
Consider the following code:
if ( some_condition )
spin_lock_irqsave( lock, flags );
else { }
If we use the `do ... while (0)' wrapper, we get this (which
is correct)
if (some_condition)
do
{
local_irq_save (flags);
spin_lock (lock);
}
while (0);
else
{
}
If we don't....we get this (which isn't)
if (some_condition)
{
local_irq_save (flags);
spin_lock (lock);
}; /* note the spurious `;' */
else
{
}
HTH,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account
for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
Clone Bernie!
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: wipeinfo, secure delete, device driver
Date: Mon, 26 Mar 2001 12:48:16 +0000
Kevin B. Haywood wrote:
>
> Alexander Viro wrote:
>
> > What part of "| tr '\0' '\377'" is too hard to understand?
> >
>
> Very good. Thank you. I was making the problem too difficult.
> I use:
> dd if=/dev/zero of=/dev/hda to write zero's
> So my new command is:
> dd if=dev/zero | tr \000 \ 377 | dd of=/dev/hda
>
> right?
>
> Kevin
No need to use dd, just type:
tr '\0' '\377' </dev/zero | cat >/dev/hda
But personally I would expect this to be safer:
for i in 1 2 3 4 5
do
cat /dev/urandom >/dev/hda
tr '\0' '\377' </dev/zero | cat >/dev/hda
cat /dev/zero >/dev/hda
done
But this is quite slow, 20 seconds pr. MB on a
450MHz Pentium III.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: kernel problem
Date: Mon, 26 Mar 2001 13:31:40 +0000
Werner K�hnert wrote:
>
[...]
> >
> > In arch/i386/kernel/traps.c change the line:
> > regs->eip = fixup;
> > into
> > printk("fixup: %08X=>%08X regs=%08X
> > regs->esp=%08X\n",regs->eip,fixup,regs,regs->esp);
> > regs->eip = fixup;
> >
> > --
> > Kasper Dupont
>
> I did that and the output is :
>
> fixup: C0197A11=>C0198784 regs=C01C7FA8 regs->esp=00000010
>
> and then the output as before.
> Is there any way to get the symbol table for the actual kernel and do You have a clue
> which interrupt function this could be ? Maybe my hardware does something strange.
>
> Regards,
> Werner
>
> --
>
> Werner Kuehnert Siemens AG Oesterreich PSE ECT IPN 1
> E-Mail: [EMAIL PROTECTED]
When compiling the kernel the symbol table is saved in
a file named System.map.
I don't know if looking up the outputs from the above
list will give us any clue about what happens.
The esp value is for sure wrong, I'm not sure if this
was the value of ESP before or after the failing IRET
instruction. (assuming that it really was the IRET
instruction failing.)
Adding printk("%08X\n",*(unsigned long*)regs->eip));
should print the failing instruction, it might be nice
to verify that it is really the IRET.
I'm not sure which interrupt is ariving at this point.
I would expect a timer interrupt, but some error might
cause another interrupt to arrive.
Inserting printk() statements in all interrupt handlers
might reveal which one is actually being executed, that
might be the only step forward.
I do find it strange that you only get one single fixup,
I would have expected a longer list.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Process Scheduler/Resource Management
Date: Mon, 26 Mar 2001 13:44:29 +0000
Kasper Dupont wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > ++Viage
> >
> > P.S.: BTW: Can I tell a process to use only CPU no. X and
> > not one ot the other CPUs?
>
> I don't think so, but I believe it will come some day.
> It will be useful in particular in some parts of the
> kernel which currently use some strange hacks to force
> code onto the first CPU.
>
I have looked on the scheduler in 2.4.1 and,
it actually has this feature. But it is not
yet used anywhere in the kernel.
The task_struct now has a cpus_allowed field,
it is a bitmask of allowed CPUs. It is
initialized to -1 (All CPUs) in the init task.
It is inherited by children, and not changed
anywhere, so all processes is allowed to run
on all CPUs.
If you want to change it, I think you could
write something like this in a kernel module:
int setallowed(unsigned long a){
if (a & ((1<<smp_num_cpus)-1)) {
current->cpus_allowed=a;
return 0;
}
else
return -EINVAL;
}
Notice this is not tested, and if you need
to use from userspace some interface must
be implemented.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Process Scheduler/Resource Management
Date: Mon, 26 Mar 2001 13:50:25 +0000
Kasper Dupont wrote:
>
[...]
>
> int setallowed(unsigned long a){
> if (a & ((1<<smp_num_cpus)-1)) {
> current->cpus_allowed=a;
> return 0;
> }
> else
> return -EINVAL;
> }
>
Perhaps this would be better:
int setallowed(unsigned long a){
if (a & ((1<<smp_num_cpus)-1)) {
current->cpus_allowed=a;
while (!(a&(1<<current->processor))) {
current->need_resched=1;
schedule();
}
return 0;
}
else
return -EINVAL;
}
--
Kasper Dupont
------------------------------
From: "jbhuang" <[EMAIL PROTECTED]>
Subject: Question about printk
Date: Mon, 26 Mar 2001 22:03:02 +0800
I have been confused by function "printk"
in the start_kernel, it will
printk(linux_banner);
but at this time, the initial value of console_drivers is still NULL;
struct console *console_drivers = NULL;
How can it print string?
Thank you for your help.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Question about printk
Date: Mon, 26 Mar 2001 14:08:18 +0000
jbhuang wrote:
>
> I have been confused by function "printk"
> in the start_kernel, it will
> printk(linux_banner);
> but at this time, the initial value of console_drivers is still NULL;
> struct console *console_drivers = NULL;
>
> How can it print string?
> Thank you for your help.
I think this comment from printk.c answers your question:
/*
* The console driver calls this routine during kernel initialization
* to register the console printing procedure with printk() and to
* print any messages that were printed by the kernel before the
* console driver was initialized.
*/
void register_console(struct console * console)
--
Kasper Dupont
------------------------------
From: Clifford Kite <[EMAIL PROTECTED]>
Subject: Re: Change in PPP handling from 2.4.0 to 2.4.1?
Date: Mon, 26 Mar 2001 08:24:43 -0600
Birger Toedtmann <[EMAIL PROTECTED]> wrote:
> I had PPP configured in my 2.4.0. It worked fine with a
> modem on /dev/ttyS0 and pppd-2.3.11.
> Now I switched to 2.4.1 (also tried 2.4.2, to no avail) and
> conquered a strange behaviour:
> - /dev/ttyS0 works fine with pppd, modem is dialing,
> connect is made
> - pppd quits with ioctl(PPPIOCGFLAGS): invalid argument
You didn't read the kernel source Documentation/Changes file, something
that is a virtual requirement when changing a kernel series. The 2.4.0
kernel let you get away with using pppd 2.3.11 but no other 2.4.x
kernel will.
The site for pppd has changed, you'll find now at ftp.samba.org in
/pub/ppp. The version of 2.4.1 pppd came out yesterday and is the
one to get.
--
Clifford Kite <kite@inet%port.com> Not a guru. (tm)
/* Better is the enemy of good enough. */
------------------------------
** 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
******************************
