few days ago i started to port driver for our hardware in company from
windows to linux. It is simple ISA card, which gives me interrupt each
8ms. So i can check it state and latch some sort of watchdog on it -
saying that i am still running (just for security, if system hangs card
is blocking all inputs/outputs).
But anyway, i was collecting all data from the card in dynamically
allocated memory. This gives me at least 300 * 20 bytes allocated. i
have sigle small allocation running on each interrupt.
Driver is working fine under win2k even if i collect as much as 10000
allocations, afterwards system uses loads of processor.
Linux (2.4.19 ,2.4.20, 2.4.21-pre[1,2,3,4] i tried so far) gives me oups
arount 80th allocation.
>From http://hit-six.co.uk/~gj/testmod.tar.bz2 you can download simple
module that shows what happends. But be carefull, it oupses very fast !
system is running up2dated Debian(stable), and i am using gcc version:
gcc version 2.95.4 20011002
--
Grzegorz Jaskiewicz <[email protected]>
K4 Labs
On Mon, 2003-02-03 at 16:13, Grzegorz Jaskiewicz wrote:
> few days ago i started to port driver for our hardware in company from
> windows to linux. It is simple ISA card, which gives me interrupt each
> 8ms. So i can check it state and latch some sort of watchdog on it -
> saying that i am still running (just for security, if system hangs card
> is blocking all inputs/outputs).
> #include <linux/modversions.h>
don't do that. ever.
> #ifdef CONFIG_KMOD
> #include <linux/kmod.h>
> #endif
bullshit ifdef's (and the surrounding code has a whole bunch too
btw you do know you can't do vmalloc (or vfree) from interrupt context ?
And that every vmalloc eats at minimum 8Kb of virtual memory space? Of
which you can't count on having more than 64Mb on x86 ?
On Mon, 2003-02-03 at 16:13, Grzegorz Jaskiewicz wrote:
> few days ago i started to port driver for our hardware in company from
> windows to linux. It is simple ISA card, which gives me interrupt each
> 8ms. So i can check it state and latch some sort of watchdog on it -
> saying that i am still running (just for security, if system hangs card
> is blocking all inputs/outputs).
forgot to tell you that
ttimer.expires = jiffies+(HZ/150.0);
you CANNOT use floating point in kernel mode! And that for HZ=100 this
gives you a timer that expires immediatly.
and that
printk("<1>%d\n", TimerIntrpt);
you shouldn't use <1> in printk strings ever.
Am Montag, 3. Februar 2003 16:13 schrieb Grzegorz Jaskiewicz:
> few days ago i started to port driver for our hardware in company from
> windows to linux. It is simple ISA card, which gives me interrupt each
> 8ms. So i can check it state and latch some sort of watchdog on it -
> saying that i am still running (just for security, if system hangs card
> is blocking all inputs/outputs).
>
> But anyway, i was collecting all data from the card in dynamically
> allocated memory. This gives me at least 300 * 20 bytes allocated. i
> have sigle small allocation running on each interrupt.
>
> Driver is working fine under win2k even if i collect as much as 10000
> allocations, afterwards system uses loads of processor.
It seems that you are using vmalloc in an interrupt handler.
That you must not do. To allocate memory in an interrupt handler
you have to use kmalloc() with GFP_ATOMIC as a second argument.
HTH
Oliver
On Mon, Feb 03, 2003 at 03:35:57PM +0000, Grzegorz Jaskiewicz wrote:
> On Mon, 2003-02-03 at 15:19, Arjan van de Ven wrote:
> > > #include <linux/modversions.h>
> > don't do that. ever.
> why ?
because if you ever need it, modules.h will automatically include
it for you already. And if it doesn't you don't need it and it does more
harm than good.
> > > #ifdef CONFIG_KMOD
> > > #include <linux/kmod.h>
> > > #endif
> >
> > bullshit ifdef's (and the surrounding code has a whole bunch too
> this has been taken from first from edge module, just to put it into example ;)
it's wrong, for the same reason as the modversions include is wrong
> > btw you do know you can't do vmalloc (or vfree) from interrupt context ?
> > And that every vmalloc eats at minimum 8Kb of virtual memory space? Of
> > which you can't count on having more than 64Mb on x86 ?
> I didn't knew that. I have at least as i said 300 of those, if user
> space software is doing something else. In practice i have around 30.
> even if 1000 it gives 1000*8kb=8MB so it is not that bad.
the 64Mb vmalloc limit is a system wide one... and
shared between threads allocating their LDT etc etc.
> Whatver, should i consider timer as interrupt too ?
timers are run in interrupt context yes... so you can't do vmalloc
or vfree there.
Greetings,
Arjan van de Ven
--
But when you distribute the same sections as part of a whole which is a work
based on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the entire whole,
and thus to each and every part regardless of who wrote it. [sect.2 GPL]
On Mon, 2003-02-03 at 16:18, Alan Cox wrote:
> Firstly vmalloc isnt permitted in interrupt context (use kmalloc with GFP_KERNEL),
> although for such small chunks you might want to vmalloc a bigger buffer once
> at startup.
i've allso tried kmalloc with the same result.
Also, in this example it is timer - module isn't cleanly wroted becouse
it supose to be only an example.
--
Grzegorz Jaskiewicz <[email protected]>
K4 Labs
On Mon, 2003-02-03 at 15:19, Arjan van de Ven wrote:
> > #include <linux/modversions.h>
> don't do that. ever.
why ?
> > #ifdef CONFIG_KMOD
> > #include <linux/kmod.h>
> > #endif
>
> bullshit ifdef's (and the surrounding code has a whole bunch too
this has been taken from first from edge module, just to put it into example ;)
> btw you do know you can't do vmalloc (or vfree) from interrupt context ?
> And that every vmalloc eats at minimum 8Kb of virtual memory space? Of
> which you can't count on having more than 64Mb on x86 ?
I didn't knew that. I have at least as i said 300 of those, if user
space software is doing something else. In practice i have around 30.
even if 1000 it gives 1000*8kb=8MB so it is not that bad. This mashine
has 128MB atleast.
Whatver, should i consider timer as interrupt too ?
--
Grzegorz Jaskiewicz <[email protected]>
K4 Labs
On Mon, 2003-02-03 at 15:22, Arjan van de Ven wrote:
> On Mon, 2003-02-03 at 16:13, Grzegorz Jaskiewicz wrote:
> forgot to tell you that
>
> ttimer.expires = jiffies+(HZ/150.0);
>
>
> you CANNOT use floating point in kernel mode! And that for HZ=100 this
> gives you a timer that expires immediatly.
In real world i am NOT using this timer that way, so please don't even
bother yourself telling me that this way is wrong, becouse i know it is
not completly ok.
>
> and that
> printk("<1>%d\n", TimerIntrpt);
> you shouldn't use <1> in printk strings ever.
<1>gives me messages on screen on my box, thats why.
the same effect is while using kmalloc, just change vmalloc to kmalloc.
--
Grzegorz Jaskiewicz <[email protected]>
K4 Labs
On 3 Feb 2003, Grzegorz Jaskiewicz wrote:
> few days ago i started to port driver for our hardware in company from
> windows to linux. It is simple ISA card, which gives me interrupt each
> 8ms. So i can check it state and latch some sort of watchdog on it -
> saying that i am still running (just for security, if system hangs card
> is blocking all inputs/outputs).
>
> But anyway, i was collecting all data from the card in dynamically
> allocated memory. This gives me at least 300 * 20 bytes allocated. i
> have sigle small allocation running on each interrupt.
>
> Driver is working fine under win2k even if i collect as much as 10000
> allocations, afterwards system uses loads of processor.
>
> Linux (2.4.19 ,2.4.20, 2.4.21-pre[1,2,3,4] i tried so far) gives me oups
> arount 80th allocation.
>
> >From http://hit-six.co.uk/~gj/testmod.tar.bz2 you can download simple
> module that shows what happends. But be carefull, it oupses very fast !
>
> system is running up2dated Debian(stable), and i am using gcc version:
> gcc version 2.95.4 20011002
I doubt that there is a bug in vmalloc or kmalloc as you state because
the machine wouldn't work at all. So, I tried to download your sources.
The file web-page claims that it's a ".bz2" file. However, once
downloaded, it becomes a "*.tar.tar" file (whatever that is). An attempt
to extract it with `tar` as `tar -xzf` fails, as does `tar -xf`. Attempts
to un-bz2 it with bzip2 or even bzip2recover fails also.
So, if you want some help finding the problems, please email me
a 'tar.gz` file directly.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Mon, 2003-02-03 at 16:18, Alan Cox wrote:
> Firstly vmalloc isnt permitted in interrupt context (use kmalloc with GFP_KERNEL),
> although for such small chunks you might want to vmalloc a bigger buffer once
> at startup.
i've allso tried kmalloc with the same result.
Also, in this example it is timer - module isn't cleanly wroted becouse
it supose to be only an example.
--
Grzegorz Jaskiewicz <[email protected]>
K4 Labs
On Mon, Feb 03, 2003 at 03:42:06PM +0000, Grzegorz Jaskiewicz wrote:
> > and that
> > printk("<1>%d\n", TimerIntrpt);
> > you shouldn't use <1> in printk strings ever.
> <1>gives me messages on screen on my box, thats why.
>
> the same effect is while using kmalloc, just change vmalloc to kmalloc.
#include <linux/kernel.h>
and then use
printk(KERN_CRIT "%d\n", TimerIntrpt);
We have these definitions for a reason. 8)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Em Mon, Feb 03, 2003 at 03:52:25PM +0000, Russell King escreveu:
> On Mon, Feb 03, 2003 at 03:42:06PM +0000, Grzegorz Jaskiewicz wrote:
> > > and that
> > > printk("<1>%d\n", TimerIntrpt);
> > > you shouldn't use <1> in printk strings ever.
> > <1>gives me messages on screen on my box, thats why.
Also look at /proc/sys/kernel/printk and
Documentation/sysctl/kernel.txt
- Arnaldo
On Mon, 2003-02-03 at 15:52, Russell King wrote:
> On Mon, Feb 03, 2003 at 03:42:06PM +0000, Grzegorz Jaskiewicz wrote:
> > > and that
> > > printk("<1>%d\n", TimerIntrpt);
> > > you shouldn't use <1> in printk strings ever.
> > <1>gives me messages on screen on my box, thats why.
> >
> > the same effect is while using kmalloc, just change vmalloc to kmalloc.
>
> #include <linux/kernel.h>
>
> and then use
>
> printk(KERN_CRIT "%d\n", TimerIntrpt);
>
> We have these definitions for a reason. 8)
Thx guys, i am concidering this as my lack of information.
But anyway, i am really impressed in spead of response.
Chears :)
--
Grzegorz Jaskiewicz <[email protected]>
K4 Labs
On Mon, 2003-02-03 at 15:40, Grzegorz Jaskiewicz wrote:
> On Mon, 2003-02-03 at 16:18, Alan Cox wrote:
>
> > Firstly vmalloc isnt permitted in interrupt context (use kmalloc with GFP_KERNEL),
> > although for such small chunks you might want to vmalloc a bigger buffer once
> > at startup.
> i've allso tried kmalloc with the same result.
> Also, in this example it is timer - module isn't cleanly wroted becouse
> it supose to be only an example.
If I build the example using the cleanups I suggested it works for me. The FPU one btw
seems to be a red herring, my gcc is outputting a precomputed integer constant
Alan
On Mon, 2003-02-03 at 16:40, Grzegorz Jaskiewicz wrote:
> On Mon, 2003-02-03 at 16:18, Alan Cox wrote:
>
> > Firstly vmalloc isnt permitted in interrupt context (use kmalloc with GFP_KERNEL),
> > although for such small chunks you might want to vmalloc a bigger buffer once
> > at startup.
> i've allso tried kmalloc with the same result.
> Also, in this example it is timer - module isn't cleanly wroted becouse
> it supose to be only an example.
I suppose you meant kmalloc with GFP_ATOMIC...
--
Benjamin Herrenschmidt <[email protected]>
On Mon, 2003-02-03 at 17:18, Alan Cox wrote:
> If I build the example using the cleanups I suggested it works for me. The FPU one btw
> seems to be a red herring, my gcc is outputting a precomputed integer constant
This is purely coincidence. GCC is perfectly entitled to use integer
arithmetic even though you used floats in the source.
GCC is likewise perfectly entitled to use floating point even if you
only used integers in the source. There's a good reason why the SH port
builds with '-mno-implicit-fp' and why all other ports should have this
_before_ it becomes a problem rather than afterwards.
--
dwmw2
On Mon, 2003-02-03 at 15:35, Arjan van de Ven wrote:
> On Mon, Feb 03, 2003 at 03:35:57PM +0000, Grzegorz Jaskiewicz wrote:
> > On Mon, 2003-02-03 at 15:19, Arjan van de Ven wrote:
> > > > #include <linux/modversions.h>
> > > don't do that. ever.
> > why ?
>
> because if you ever need it, modules.h will automatically include
> it for you already. And if it doesn't you don't need it and it does more
> harm than good.
Is that true? I thought the kernel build system added it with the
-include argument to gcc? And so it works properly _only_ if you're
using the correct way of building out-of-tree modules, which as
discussed recently on this list is
make -C $LINUXDIR SUBDIRS=`pwd`
where LINUXDIR defaults to /lib/modules/`uname -r`/build unless the user
specifies otherwise.
Some distributions ship a kernel-source package which is broken and does
not work like this. File that as a bug if you encounter it.
/me runs from Arjan :)
--
dwmw2
On Mon, 2003-02-03 at 23:54, David Woodhouse wrote:
> GCC is likewise perfectly entitled to use floating point even if you
> only used integers in the source. There's a good reason why the SH port
> builds with '-mno-implicit-fp' and why all other ports should have this
> _before_ it becomes a problem rather than afterwards.
I'm sorry, but it seems you forgot to use the -u option in your diff.
On Mon, Feb 03, 2003 at 10:54:06PM +0000, David Woodhouse wrote:
> GCC is likewise perfectly entitled to use floating point even if you
> only used integers in the source. There's a good reason why the SH port
> builds with '-mno-implicit-fp' and why all other ports should have this
> _before_ it becomes a problem rather than afterwards.
I was wondering about this yesterday when toying with the -march options
we now pass. With (for eg) -march=c3, we now tell gcc it can emit 3dnow
instructions if it wants, likewise SSE/SSE2 in other -march options.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs