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 me
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-s
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-
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 o
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
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-crunchi
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
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
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 availa
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 nee
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 comp
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 get
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
>>>
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 a
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 t
> 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
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 EVERYTH
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 no
>
> 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
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
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 tr
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
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 "v
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,
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 addres
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 func
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 cod
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 = 000
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 =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd expor
29 matches
Mail list logo
