Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
CPU: 0
EIP: 0060:[<c016d013>] Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: 00000000 ebx: 00000246 ecx: f8913300 edx: 6814ec83
esi: 00000000 edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 00000000 00000000 f8913013 f7fff880 000000d0 00000000 ef27e000
c012b907 ffffffff 00000000 c0140279 bffedc07 bffedc08 0807a018 00000000
c0102b82 0807a018 000018c9 0807a008 00000000 00000000 bffeabc8 00000080
Call Trace:
[<f8913013>] init_module+0x13/0x48 [MemDev]
[<c012b907>] blocking_notifier_call_chain+0x17/0x20
[<c0140279>] sys_init_module+0xd9/0x140
[<c0102b82>] sysenter_past_esp+0x5f/0x85
=======================
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24 08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0 74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [<c016d013>] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include <linux/autoconf.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/poll.h>
#include <linux/mm.h>
static const char devname[]="Device";
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
return -ENOMEM;
}
return 0;
}
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Cleanup the module in preparation for removal.
//
static void quit() {
kfree(info);
printk(KERN_INFO"%s : Module removed\n", devname);
}
MODULE_LICENSE("GPL");
MODULE_ALIAS("MemDev");
module_init(startup);
module_exit(quit);
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Anybody have a clue why this should error out? Am I using
some reserved names??? I got rid of __init and anything
else that I thought could cause the fault, plus got rid
of all the code!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
>
>
> Here is a so-called BUG when trying to insert the following
> module into the kernel (2.6.22.1).
>
>
> BUG: unable to handle kernel paging request at virtual address 6814ec83
> printing eip:
> c016d013
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT SMP
> Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
> CPU: 0
> EIP: 0060:[<c016d013>] Not tainted VLI
> EFLAGS: 00010046 (2.6.22.1 #2)
> EIP is at kmem_cache_alloc+0x23/0x80
> eax: 00000000 ebx: 00000246 ecx: f8913300 edx: 6814ec83
> esi: 00000000 edi: f8913000 ebp: ef27e000 esp: ef27ff74
> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
> Stack: f8913300 00000000 00000000 f8913013 f7fff880 000000d0 00000000 ef27e000
> c012b907 ffffffff 00000000 c0140279 bffedc07 bffedc08 0807a018 00000000
> c0102b82 0807a018 000018c9 0807a008 00000000 00000000 bffeabc8 00000080
> Call Trace:
> [<f8913013>] init_module+0x13/0x48 [MemDev]
> [<c012b907>] blocking_notifier_call_chain+0x17/0x20
> [<c0140279>] sys_init_module+0xd9/0x140
> [<c0102b82>] sysenter_past_esp+0x5f/0x85
> =======================
> Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24 08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0 74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
> EIP: [<c016d013>] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
>
>
>
> Here is the code that causes the crash.
>
>
> #include <linux/autoconf.h>
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/poll.h>
> #include <linux/mm.h>
> static const char devname[]="Device";
> #define NR_PAGES 0x10
>
> struct DMA {
> void *ptr;
> unsigned long addr;
> size_t len;
> };
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> //
> // The top-level object that gets allocated once, when the module is
> // installed.
> //
> struct INFO {
> struct file_operations fa; // Kernel connection
> struct semaphore dev_sem;
> struct DMA dma[NR_PAGES]; // Can map one megabyte
> uint32_t vm_start; // Where mmap() starts
> uint32_t pages; // Number of pages mapped
> atomic_t open; // Number of opens
> };
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> static struct INFO *info;
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> //
> // Initialize the module and return 0 if everything is okay.
> // Return a negative error-code if not.
> //
> static int32_t startup()
> {
> if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
> printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
Missing space after KERN_ALERT?
> return -ENOMEM;
> }
> return 0;
> }
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> //
> // Cleanup the module in preparation for removal.
> //
> static void quit() {
> kfree(info);
> printk(KERN_INFO"%s : Module removed\n", devname);
> }
> MODULE_LICENSE("GPL");
> MODULE_ALIAS("MemDev");
> module_init(startup);
> module_exit(quit);
> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Anybody have a clue why this should error out? Am I using
> some reserved names??? I got rid of __init and anything
> else that I thought could cause the fault, plus got rid
> of all the code!
--
Len Sorensen
On Dec 19 2007 15:10, linux-os (Dick Johnson) wrote:
>I got rid of __init and anything else that I thought could cause the fault,
I anticipate the day removing __init causes a breakage, heh.
I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it?
>plus got rid of all the code!
>static int32_t startup()
I noticed that. Where's your "void" gone? :-)
And usually, the init routine returns int, not int32_t,
even if it's the same in current development models.
(I don't think you run an ILP64-compiled kernel.)
#include <linux/autoconf.h> is also not advised.
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
>
>
> Here is a so-called BUG when trying to insert the following
> module into the kernel (2.6.22.1).
>
>
> MODULE_ALIAS("MemDev");
> module_init(startup);
> module_exit(quit);
Just a wild guess. Your init and exit functions uses some generic names.
Have you tried renaming them to usual style like:
memdev_init
memdev_exit
So you have no clashes with existing global symbols.
Sam
On Wed, 19 Dec 2007, Lennart Sorensen wrote:
> On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
>>
>>
>> Here is a so-called BUG when trying to insert the following
>> module into the kernel (2.6.22.1).
>>
>>
>> BUG: unable to handle kernel paging request at virtual address 6814ec83
>> printing eip:
>> c016d013
>> *pde = 00000000
>> Oops: 0000 [#1]
>> PREEMPT SMP
>> Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
>> CPU: 0
>> EIP: 0060:[<c016d013>] Not tainted VLI
>> EFLAGS: 00010046 (2.6.22.1 #2)
>> EIP is at kmem_cache_alloc+0x23/0x80
>> eax: 00000000 ebx: 00000246 ecx: f8913300 edx: 6814ec83
>> esi: 00000000 edi: f8913000 ebp: ef27e000 esp: ef27ff74
>> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
>> Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
>> Stack: f8913300 00000000 00000000 f8913013 f7fff880 000000d0 00000000 ef27e000
>> c012b907 ffffffff 00000000 c0140279 bffedc07 bffedc08 0807a018 00000000
>> c0102b82 0807a018 000018c9 0807a008 00000000 00000000 bffeabc8 00000080
>> Call Trace:
>> [<f8913013>] init_module+0x13/0x48 [MemDev]
>> [<c012b907>] blocking_notifier_call_chain+0x17/0x20
>> [<c0140279>] sys_init_module+0xd9/0x140
>> [<c0102b82>] sysenter_past_esp+0x5f/0x85
>> =======================
>> Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24 08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0 74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
>> EIP: [<c016d013>] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
>>
>>
>>
>> Here is the code that causes the crash.
>>
>>
>> #include <linux/autoconf.h>
>> #include <linux/module.h>
>> #include <linux/kernel.h>
>> #include <linux/init.h>
>> #include <linux/poll.h>
>> #include <linux/mm.h>
>> static const char devname[]="Device";
>> #define NR_PAGES 0x10
>>
>> struct DMA {
>> void *ptr;
>> unsigned long addr;
>> size_t len;
>> };
>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> //
>> // The top-level object that gets allocated once, when the module is
>> // installed.
>> //
>> struct INFO {
>> struct file_operations fa; // Kernel connection
>> struct semaphore dev_sem;
>> struct DMA dma[NR_PAGES]; // Can map one megabyte
>> uint32_t vm_start; // Where mmap() starts
>> uint32_t pages; // Number of pages mapped
>> atomic_t open; // Number of opens
>> };
>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> static struct INFO *info;
>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> //
>> // Initialize the module and return 0 if everything is okay.
>> // Return a negative error-code if not.
>> //
>> static int32_t startup()
>> {
>> if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
>> printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
>
> Missing space after KERN_ALERT?
I certainly hope that it's not the problem! That would
invalidate both the kernel and the compiler!
>
> --
> Len Sorensen
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Wed, 19 Dec 2007, Jan Engelhardt wrote:
>
> On Dec 19 2007 15:10, linux-os (Dick Johnson) wrote:
>
>
>> I got rid of __init and anything else that I thought could cause the fault,
>
> I anticipate the day removing __init causes a breakage, heh.
> I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it?
>
>> plus got rid of all the code!
>> static int32_t startup()
>
> I noticed that. Where's your "void" gone? :-)
What void???
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Dec 19 2007 16:10, linux-os (Dick Johnson) wrote:
>> I anticipate the day removing __init causes a breakage, heh.
>> I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it?
>>
>>> plus got rid of all the code!
>>> static int32_t startup()
>>
>> I noticed that. Where's your "void" gone? :-)
>
>What void???
>
static __init int startup(void)
{
...
}
Just a stylistic thing, but it has got a clear semantic difference to ().
On Wed, Dec 19, 2007 at 03:56:45PM -0500, linux-os (Dick Johnson) wrote:
>
> On Wed, 19 Dec 2007, Lennart Sorensen wrote:
>
> > On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
> >>
> >>
> >> Here is a so-called BUG when trying to insert the following
> >> module into the kernel (2.6.22.1).
> >>
> >>
> >> BUG: unable to handle kernel paging request at virtual address 6814ec83
> >> printing eip:
> >> c016d013
> >> *pde = 00000000
> >> Oops: 0000 [#1]
> >> PREEMPT SMP
> >> Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
> >> CPU: 0
> >> EIP: 0060:[<c016d013>] Not tainted VLI
> >> EFLAGS: 00010046 (2.6.22.1 #2)
> >> EIP is at kmem_cache_alloc+0x23/0x80
> >> eax: 00000000 ebx: 00000246 ecx: f8913300 edx: 6814ec83
> >> esi: 00000000 edi: f8913000 ebp: ef27e000 esp: ef27ff74
> >> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> >> Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
> >> Stack: f8913300 00000000 00000000 f8913013 f7fff880 000000d0 00000000 ef27e000
> >> c012b907 ffffffff 00000000 c0140279 bffedc07 bffedc08 0807a018 00000000
> >> c0102b82 0807a018 000018c9 0807a008 00000000 00000000 bffeabc8 00000080
> >> Call Trace:
> >> [<f8913013>] init_module+0x13/0x48 [MemDev]
> >> [<c012b907>] blocking_notifier_call_chain+0x17/0x20
> >> [<c0140279>] sys_init_module+0xd9/0x140
> >> [<c0102b82>] sysenter_past_esp+0x5f/0x85
> >> =======================
> >> Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24 08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0 74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
> >> EIP: [<c016d013>] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
> >>
> >>
> >>
> >> Here is the code that causes the crash.
> >>
> >>
> >> #include <linux/autoconf.h>
> >> #include <linux/module.h>
> >> #include <linux/kernel.h>
> >> #include <linux/init.h>
> >> #include <linux/poll.h>
> >> #include <linux/mm.h>
> >> static const char devname[]="Device";
> >> #define NR_PAGES 0x10
> >>
> >> struct DMA {
> >> void *ptr;
> >> unsigned long addr;
> >> size_t len;
> >> };
> >> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >> //
> >> // The top-level object that gets allocated once, when the module is
> >> // installed.
> >> //
> >> struct INFO {
> >> struct file_operations fa; // Kernel connection
> >> struct semaphore dev_sem;
> >> struct DMA dma[NR_PAGES]; // Can map one megabyte
> >> uint32_t vm_start; // Where mmap() starts
> >> uint32_t pages; // Number of pages mapped
> >> atomic_t open; // Number of opens
> >> };
> >> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >> static struct INFO *info;
> >> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >> //
> >> // Initialize the module and return 0 if everything is okay.
> >> // Return a negative error-code if not.
> >> //
> >> static int32_t startup()
> >> {
> >> if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
> >> printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
> >
> > Missing space after KERN_ALERT?
>
> I certainly hope that it's not the problem! That would
> invalidate both the kernel and the compiler!
It was the only thing that looked a bit odd. Although white space
generally shouldn't matter in C.
Well maybe the module was just compiled against a different source tree
than the running kernel it was loaded into.
I suppose comment out the printk and see if it's breaking on that line
or somewhere else. Or just make it a printk with no variables.
--
Len Sorensen
On Thu, 20 Dec 2007, Lennart Sorensen wrote:
> On Wed, Dec 19, 2007 at 03:56:45PM -0500, linux-os (Dick Johnson) wrote:
>>
>> On Wed, 19 Dec 2007, Lennart Sorensen wrote:
>>
>>> On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
>>>>
>>>>
>>>> Here is a so-called BUG when trying to insert the following
>>>> module into the kernel (2.6.22.1).
>>>>
>>>>
>>>> BUG: unable to handle kernel paging request at virtual address 6814ec83
>>>> printing eip:
>>>> c016d013
>>>> *pde = 00000000
>>>> Oops: 0000 [#1]
>>>> PREEMPT SMP
>>>> Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
>>>> CPU: 0
>>>> EIP: 0060:[<c016d013>] Not tainted VLI
>>>> EFLAGS: 00010046 (2.6.22.1 #2)
>>>> EIP is at kmem_cache_alloc+0x23/0x80
>>>> eax: 00000000 ebx: 00000246 ecx: f8913300 edx: 6814ec83
>>>> esi: 00000000 edi: f8913000 ebp: ef27e000 esp: ef27ff74
>>>> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
>>>> Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
>>>> Stack: f8913300 00000000 00000000 f8913013 f7fff880 000000d0 00000000 ef27e000
>>>> c012b907 ffffffff 00000000 c0140279 bffedc07 bffedc08 0807a018 00000000
>>>> c0102b82 0807a018 000018c9 0807a008 00000000 00000000 bffeabc8 00000080
>>>> Call Trace:
>>>> [<f8913013>] init_module+0x13/0x48 [MemDev]
>>>> [<c012b907>] blocking_notifier_call_chain+0x17/0x20
>>>> [<c0140279>] sys_init_module+0xd9/0x140
>>>> [<c0102b82>] sysenter_past_esp+0x5f/0x85
>>>> =======================
>>>> Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24 08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0 74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
>>>> EIP: [<c016d013>] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
>>>>
>>>>
>>>>
>>>> Here is the code that causes the crash.
>>>>
>>>>
>>>> #include <linux/autoconf.h>
>>>> #include <linux/module.h>
>>>> #include <linux/kernel.h>
>>>> #include <linux/init.h>
>>>> #include <linux/poll.h>
>>>> #include <linux/mm.h>
>>>> static const char devname[]="Device";
>>>> #define NR_PAGES 0x10
>>>>
>>>> struct DMA {
>>>> void *ptr;
>>>> unsigned long addr;
>>>> size_t len;
>>>> };
>>>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>> //
>>>> // The top-level object that gets allocated once, when the module is
>>>> // installed.
>>>> //
>>>> struct INFO {
>>>> struct file_operations fa; // Kernel connection
>>>> struct semaphore dev_sem;
>>>> struct DMA dma[NR_PAGES]; // Can map one megabyte
>>>> uint32_t vm_start; // Where mmap() starts
>>>> uint32_t pages; // Number of pages mapped
>>>> atomic_t open; // Number of opens
>>>> };
>>>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>> static struct INFO *info;
>>>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>> //
>>>> // Initialize the module and return 0 if everything is okay.
>>>> // Return a negative error-code if not.
>>>> //
>>>> static int32_t startup()
>>>> {
>>>> if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
>>>> printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
>>>
>>> Missing space after KERN_ALERT?
>>
>> I certainly hope that it's not the problem! That would
>> invalidate both the kernel and the compiler!
>
> It was the only thing that looked a bit odd. Although white space
> generally shouldn't matter in C.
>
> Well maybe the module was just compiled against a different source tree
> than the running kernel it was loaded into.
>
> I suppose comment out the printk and see if it's breaking on that line
> or somewhere else. Or just make it a printk with no variables.
>
> --
> Len Sorensen
>
It never gets to the printk(). You were right about the
compilation. Somebody changed the kernel to compile with
parameter passing in REGISTERS! This means that EVERYTHING
needs to be compiled the same way, 'C' calling conventions
were not good enough!
FYI, it has been previously shown that passing parameters
in registers on register-starved ix86 machines is always
a loss, because the registers need to be freed up, either
by saving them on the stack or as dummy memory variables.
Now, they've done it to the entire kernel!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote:
> It never gets to the printk(). You were right about the
> compilation. Somebody changed the kernel to compile with
> parameter passing in REGISTERS! This means that EVERYTHING
> needs to be compiled the same way, 'C' calling conventions
> were not good enough!
>
> FYI, it has been previously shown that passing parameters
> in registers on register-starved ix86 machines is always
> a loss, because the registers need to be freed up, either
> by saving them on the stack or as dummy memory variables.
>
> Now, they've done it to the entire kernel!
It's a config option. I think redhat was the first to actually start
using it on their distributions. Many distributions don't use it.
Debian does not use it on their kernels.
--
Len Sorensen
>
> It never gets to the printk(). You were right about the
> compilation. Somebody changed the kernel to compile with
> parameter passing in REGISTERS! This means that EVERYTHING
> needs to be compiled the same way, 'C' calling conventions
> were not good enough!
How did you build the module. It reads like you failed to use
kbuild to build your module which is why you did not pass
correct options to gcc - correct?
If you did not use kbuild - why not?
Is there anything missing you need?
Sam
On Thu, 20 Dec 2007, Lennart Sorensen wrote:
> On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote:
>> It never gets to the printk(). You were right about the
>> compilation. Somebody changed the kernel to compile with
>> parameter passing in REGISTERS! This means that EVERYTHING
>> needs to be compiled the same way, 'C' calling conventions
>> were not good enough!
>>
>> FYI, it has been previously shown that passing parameters
>> in registers on register-starved ix86 machines is always
>> a loss, because the registers need to be freed up, either
>> by saving them on the stack or as dummy memory variables.
>>
>> Now, they've done it to the entire kernel!
>
> It's a config option. I think redhat was the first to actually start
> using it on their distributions. Many distributions don't use it.
> Debian does not use it on their kernels.
>
> --
> Len Sorensen
> --
It doesn't seem to be something in .config. Do you know how to
reconfigure to get parameter passing put back like it was? Our
production applications have lots of assembly-language files
and I'm sure we are not going to be able to change all those!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Thu, 20 Dec 2007, Sam Ravnborg wrote:
>>
>> It never gets to the printk(). You were right about the
>> compilation. Somebody changed the kernel to compile with
>> parameter passing in REGISTERS! This means that EVERYTHING
>> needs to be compiled the same way, 'C' calling conventions
>> were not good enough!
>
> How did you build the module. It reads like you failed to use
> kbuild to build your module which is why you did not pass
> correct options to gcc - correct?
>
> If you did not use kbuild - why not?
> Is there anything missing you need?
>
> Sam
>
I need to get rid of -mregparm=3 on gcc's command line. It
is completely incompatible with the standard calling conventions
used in all our assembly-language files in our drivers. We make
very high-speed number-crunching drivers that munge high-speed
data into images. We need to do that in assembly as we have
always done.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
> It doesn't seem to be something in .config. Do you know how to
> reconfigure to get parameter passing put back like it was? Our
> production applications have lots of assembly-language files
> and I'm sure we are not going to be able to change all those!
32-bit x86 uses regparm=3 by default now since commit a1a70c25 ("i386:
always enable regparm"), which went in about a year ago. To go back
to the old way, you'll just have to edit arch/x86/Makefile_32 (and
rebuild your whole kernel from a clean tree, obviously).
- R.
On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote:
>
> On Thu, 20 Dec 2007, Sam Ravnborg wrote:
>
> >>
> >> It never gets to the printk(). You were right about the
> >> compilation. Somebody changed the kernel to compile with
> >> parameter passing in REGISTERS! This means that EVERYTHING
> >> needs to be compiled the same way, 'C' calling conventions
> >> were not good enough!
> >
> > How did you build the module. It reads like you failed to use
> > kbuild to build your module which is why you did not pass
> > correct options to gcc - correct?
> >
> > If you did not use kbuild - why not?
> > Is there anything missing you need?
> >
> > Sam
> >
>
> I need to get rid of -mregparm=3 on gcc's command line. It
> is completely incompatible with the standard calling conventions
> used in all our assembly-language files in our drivers. We make
> very high-speed number-crunching drivers that munge high-speed
> data into images. We need to do that in assembly as we have
> always done.
That I understand. So you need a CONFIG_ option to switch off
-regparm=3 and pray that the kernel assembly supports it.
And then I assume you avoided kbuild because it added -regparm=3
which is why your simple module broke.
As you are well aware there is not any testing of a kernel without
-regparm=3 these days so you should strongly consider making your
assembly module comply with -regparm=3.
And no - I dunno how much work that is and what impact it has
on your number chrunching stuff.
But it looks like the only sane long-term solution to me.
Sam
linux-os (Dick Johnson) <[email protected]> wrote:
> On Thu, 20 Dec 2007, Sam Ravnborg wrote:
>>> It never gets to the printk(). You were right about the
>>> compilation. Somebody changed the kernel to compile with
>>> parameter passing in REGISTERS! This means that EVERYTHING
>>> needs to be compiled the same way, 'C' calling conventions
>>> were not good enough!
>>
>> How did you build the module. It reads like you failed to use
>> kbuild to build your module which is why you did not pass
>> correct options to gcc - correct?
>>
>> If you did not use kbuild - why not?
>> Is there anything missing you need?
> I need to get rid of -mregparm=3 on gcc's command line. It
> is completely incompatible with the standard calling conventions
> used in all our assembly-language files in our drivers. We make
> very high-speed number-crunching drivers that munge high-speed
> data into images. We need to do that in assembly as we have
> always done.
According to my quick googling, "__attribute__((regparm,0))" is what you need.
On Thu, 20 Dec 2007 18:05:48 -0500, "linux-os (Dick Johnson)" <[email protected]> wrote:
>
> On Thu, 20 Dec 2007, Sam Ravnborg wrote:
>
> > On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote:
> >>
> >> On Thu, 20 Dec 2007, Sam Ravnborg wrote:
> >>
> >>>>
> >>>> It never gets to the printk(). You were right about the
> >>>> compilation. Somebody changed the kernel to compile with
> >>>> parameter passing in REGISTERS! This means that EVERYTHING
> >>>> needs to be compiled the same way, 'C' calling conventions
> >>>> were not good enough!
> >>>
> >>> How did you build the module. It reads like you failed to use
> >>> kbuild to build your module which is why you did not pass
> >>> correct options to gcc - correct?
> >>>
> >>> If you did not use kbuild - why not?
> >>> Is there anything missing you need?
> >>>
> >>
> >> I need to get rid of -mregparm=3 on gcc's command line. It
> >> is completely incompatible with the standard calling conventions
> >> used in all our assembly-language files in our drivers. We make
> >> very high-speed number-crunching drivers that munge high-speed
> >> data into images. We need to do that in assembly as we have
> >> always done.
>
Just for curiosity... yep, I understand now you have everything written
in assembler, but why not consider start writing it in C and stop
doing the compiler work (such as pipelining, out of order reordering,
loop unrolling for specific processor, and so on...)
That's what everyone taught me, nowadays you won't be better than the
compiler in anything longer than three lines...
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
On Thu, 20 Dec 2007, Roland Dreier wrote:
> > It doesn't seem to be something in .config. Do you know how to
> > reconfigure to get parameter passing put back like it was? Our
> > production applications have lots of assembly-language files
> > and I'm sure we are not going to be able to change all those!
>
> 32-bit x86 uses regparm=3 by default now since commit a1a70c25 ("i386:
> always enable regparm"), which went in about a year ago. To go back
> to the old way, you'll just have to edit arch/x86/Makefile_32 (and
> rebuild your whole kernel from a clean tree, obviously).
Okay. Thanks! I need to do that.
>
> - R.
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Thu, 20 Dec 2007, Sam Ravnborg wrote:
> On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote:
>>
>> On Thu, 20 Dec 2007, Sam Ravnborg wrote:
>>
>>>>
>>>> It never gets to the printk(). You were right about the
>>>> compilation. Somebody changed the kernel to compile with
>>>> parameter passing in REGISTERS! This means that EVERYTHING
>>>> needs to be compiled the same way, 'C' calling conventions
>>>> were not good enough!
>>>
>>> How did you build the module. It reads like you failed to use
>>> kbuild to build your module which is why you did not pass
>>> correct options to gcc - correct?
>>>
>>> If you did not use kbuild - why not?
>>> Is there anything missing you need?
>>>
>>> Sam
>>>
>>
>> I need to get rid of -mregparm=3 on gcc's command line. It
>> is completely incompatible with the standard calling conventions
>> used in all our assembly-language files in our drivers. We make
>> very high-speed number-crunching drivers that munge high-speed
>> data into images. We need to do that in assembly as we have
>> always done.
> That I understand. So you need a CONFIG_ option to switch off
> -regparm=3 and pray that the kernel assembly supports it.
>
> And then I assume you avoided kbuild because it added -regparm=3
> which is why your simple module broke.
>
> As you are well aware there is not any testing of a kernel without
> -regparm=3 these days so you should strongly consider making your
> assembly module comply with -regparm=3.
>
> And no - I dunno how much work that is and what impact it has
> on your number chrunching stuff.
> But it looks like the only sane long-term solution to me.
>
> Sam
>
I may be able to make a file full of "adapters" if I
can figure out how to have a procedure that gets
called with parameters in registers, with it calling
conventional stuff. There used to be a macro, "asmlinkage"
that corrected the calling conventions for assembly-language
procedures. I will try to see what it did in some
older kernels. It got taken out of newer ones.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
J.A. Magall?n wrote:
>>>>
>>>> I need to get rid of -mregparm=3 on gcc's command line. It
>>>> is completely incompatible with the standard calling conventions
>>>> used in all our assembly-language files in our drivers. We make
>>>> very high-speed number-crunching drivers that munge high-speed
>>>> data into images. We need to do that in assembly as we have
>>>> always done.
>>>>
>
> Just for curiosity... yep, I understand now you have everything written
> in assembler, but why not consider start writing it in C and stop
> doing the compiler work (such as pipelining, out of order reordering,
> loop unrolling for specific processor, and so on...)
>
> That's what everyone taught me, nowadays you won't be better than the
> compiler in anything longer than three lines...
>
>
Not true for image processing. compilers are not too good with
optimizing mmx and sse algorithms. This is why user space libraries like
ffmpeg still use assembly code.
That being said, I don't think sse and mmx are available in kernel
space, so I would have suggested doing all the grunt work in userspace
would be better for this persons application so that he could use sse
and mmx etc.
James
On Dec 21 2007 12:08, James Courtier-Dutton wrote:
> That being said, I don't think sse and mmx are available in kernel
> space, so I would have suggested doing all the grunt work in
> userspace would be better for this persons application so that he
> could use sse and mmx etc.
>
They are available, you just need to pay attention not to trash
a process's context.
IIRC this has been done for 387 FPUting. (The 'trigger' thing in
save_i387() in arch/x86/i387_32.c probably.) Probably not for SSE.
On Thu, 20 Dec 2007, Bodo Eggert wrote:
> linux-os (Dick Johnson) <[email protected]> wrote:
>> On Thu, 20 Dec 2007, Sam Ravnborg wrote:
>
>>>> It never gets to the printk(). You were right about the
>>>> compilation. Somebody changed the kernel to compile with
>>>> parameter passing in REGISTERS! This means that EVERYTHING
>>>> needs to be compiled the same way, 'C' calling conventions
>>>> were not good enough!
>>>
>>> How did you build the module. It reads like you failed to use
>>> kbuild to build your module which is why you did not pass
>>> correct options to gcc - correct?
>>>
>>> If you did not use kbuild - why not?
>>> Is there anything missing you need?
>
>> I need to get rid of -mregparm=3 on gcc's command line. It
>> is completely incompatible with the standard calling conventions
>> used in all our assembly-language files in our drivers. We make
>> very high-speed number-crunching drivers that munge high-speed
>> data into images. We need to do that in assembly as we have
>> always done.
>
> According to my quick googling, "__attribute__((regparm,0))" is what you need.
>
Yes, thanks! I don't need to change anything except the
declarations of the assembly-language stuff.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Thu, Dec 20, 2007 at 05:56:19PM -0500, linux-os (Dick Johnson) wrote:
> Okay. Thanks! I need to do that.
On the (now somewhat old) 2.6.18 kernel I use it is an option under
"Processor type and features" called "Use register arguments", but yeah
it isn't an option anymore in new kernels.
As for your argument that it isn't a good idea, well most of the time
the arguments you want to pass to a function are already values you were
just working with to get them ready for the function, so quite likely
they are already in the registers you are worried about having to clear
first. Add to that the ability of modern x86 CPUs to use rename
registers to fake stack accesses in some cases and the clearing of the
registers become pretty much a non issue, at least that's my
understanding of how things work.
--
Len Sorensen
On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote:
> I need to get rid of -mregparm=3 on gcc's command line. It
> is completely incompatible with the standard calling conventions
> used in all our assembly-language files in our drivers. We make
> very high-speed number-crunching drivers that munge high-speed
> data into images. We need to do that in assembly as we have
> always done.
Well I guess you can either fix the assembly once and for all to handle
the current linux way of doing things, or you can patch to kernel back
to the old ways of doing things when using your driver.
I suppose you could just add some wrapper functions to your assembly
that uses the new regparm calling method and then calls your methods the
old way and selectively enable those when regparm is used by the kernel
if you want to support all kernel versions. Or you could use inline
assembly in C functions to handle the calling convention for you.
--
Len Sorensen
On Fri, 21 Dec 2007, Lennart Sorensen wrote:
> On Thu, Dec 20, 2007 at 05:56:19PM -0500, linux-os (Dick Johnson) wrote:
>> Okay. Thanks! I need to do that.
>
> On the (now somewhat old) 2.6.18 kernel I use it is an option under
> "Processor type and features" called "Use register arguments", but yeah
> it isn't an option anymore in new kernels.
>
> As for your argument that it isn't a good idea, well most of the time
> the arguments you want to pass to a function are already values you were
> just working with to get them ready for the function, so quite likely
> they are already in the registers you are worried about having to clear
> first. Add to that the ability of modern x86 CPUs to use rename
> registers to fake stack accesses in some cases and the clearing of the
> registers become pretty much a non issue, at least that's my
> understanding of how things work.
>
> --
> Len Sorensen
>
If the procedures in different files or are in libraries, there
is no way for the compiler to "know."
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Fri, 21 Dec 2007, Lennart Sorensen wrote:
> On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote:
>> I need to get rid of -mregparm=3 on gcc's command line. It
>> is completely incompatible with the standard calling conventions
>> used in all our assembly-language files in our drivers. We make
>> very high-speed number-crunching drivers that munge high-speed
>> data into images. We need to do that in assembly as we have
>> always done.
>
> Well I guess you can either fix the assembly once and for all to handle
> the current linux way of doing things, or you can patch to kernel back
> to the old ways of doing things when using your driver.
>
> I suppose you could just add some wrapper functions to your assembly
> that uses the new regparm calling method and then calls your methods the
> old way and selectively enable those when regparm is used by the kernel
> if you want to support all kernel versions. Or you could use inline
> assembly in C functions to handle the calling convention for you.
>
> --
> Len Sorensen
>
It's easier that that, just declare the assembly-language
functions to be of type __attribute((regparm=0))__ or however
you spell it (I'm not at my usual machine)!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
James Courtier-Dutton wrote:
> J.A. Magall?n wrote:
>>>>>
>>>>> I need to get rid of -mregparm=3 on gcc's command line. It
>>>>> is completely incompatible with the standard calling conventions
>>>>> used in all our assembly-language files in our drivers. We make
>>>>> very high-speed number-crunching drivers that munge high-speed
>>>>> data into images. We need to do that in assembly as we have
>>>>> always done.
>>>>>
>>
>> Just for curiosity... yep, I understand now you have everything written
>> in assembler, but why not consider start writing it in C and stop
>> doing the compiler work (such as pipelining, out of order reordering,
>> loop unrolling for specific processor, and so on...)
>>
>> That's what everyone taught me, nowadays you won't be better than the
>> compiler in anything longer than three lines...
>>
>>
>
> Not true for image processing. compilers are not too good with
> optimizing mmx and sse algorithms. This is why user space libraries like
> ffmpeg still use assembly code.
If half of what I read about the Intel compiler is true, that may no
longer be true.
> That being said, I don't think sse and mmx are available in kernel
> space, so I would have suggested doing all the grunt work in userspace
> would be better for this persons application so that he could use sse
> and mmx etc.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
Lennart Sorensen wrote:
> On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote:
>> I need to get rid of -mregparm=3 on gcc's command line. It
>> is completely incompatible with the standard calling conventions
>> used in all our assembly-language files in our drivers. We make
>> very high-speed number-crunching drivers that munge high-speed
>> data into images. We need to do that in assembly as we have
>> always done.
>
> Well I guess you can either fix the assembly once and for all to handle
> the current linux way of doing things, or you can patch to kernel back
> to the old ways of doing things when using your driver.
>
> I suppose you could just add some wrapper functions to your assembly
> that uses the new regparm calling method and then calls your methods the
> old way and selectively enable those when regparm is used by the kernel
> if you want to support all kernel versions. Or you could use inline
> assembly in C functions to handle the calling convention for you.
If I were to guess, based on nothing but what's in this thread, people
who write modules in assembler would want to avoid the the wrapper
overhead. Of course putting image processing in the kernel at all
instead of user programs is not something I ever do...
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On Thu, 2007-12-20 at 11:27 -0500, Lennart Sorensen wrote:
> On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote:
> > It never gets to the printk(). You were right about the
> > compilation. Somebody changed the kernel to compile with
> > parameter passing in REGISTERS! This means that EVERYTHING
> > needs to be compiled the same way, 'C' calling conventions
> > were not good enough!
> >
> > FYI, it has been previously shown that passing parameters
> > in registers on register-starved ix86 machines is always
> > a loss, because the registers need to be freed up, either
> > by saving them on the stack or as dummy memory variables.
> >
> > Now, they've done it to the entire kernel!
>
> It's a config option. I think redhat was the first to actually start
> using it on their distributions. Many distributions don't use it.
> Debian does not use it on their kernels.
And anyway, what's wrong with having the kernel build scripts build the
module for you? ;-)
Jon.