RE : 2.6.6-rc3-mm2 : REGPARAM forced => no external module with some object code only

RE : 2.6.6-rc3-mm2 : REGPARAM forced => no external module with some object code only

[Eric Valette]

Andrew,

The Changelog says nothing really important but forcing REGPARAM is 
rather important : it breaks any external module using object only code 
that calls a kernel function.

I do not want to enter the "binary module" debate just reports facts so 
that people be aware of the problem.

I have a bewan PCI ST ADSL modem. They provide a linux driver that works 
with 2.6 like a charm but contains an object file. And of course code 
located in this object only file breaks because it calls alloc_obj:

alloc_obj:kmalloc failed,size=-742088876,type=abc0

Complete stack trace attached... (that shows they do not expect kmalloc 
to fail :-( )

Do not blame Bewan  : they have always been very responsive and do 
provide an almost GPL compliant module that works with 2.4 and 2.6 
kernels like a charm. In particular, fixing the code to support 2.6 
module generation scheme has only taken in a couple of weeks after I 
politely asked to the maintainer sending an initial patch. They are just 
dependent on STMicro (if I remember correctly) for the library that 
drives the ATM chipset and apparently they failed to ask them to open up 
their code...

Maybe they can just ask them to compile with regpram=3 but anyway as an 
end-user I have no solution...

I will report the bug to my contact...

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: Re : 2.6.6-rc3-mm2 : REGPARAM forced => no external module with some object code only

[Eric Valette]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

Eric Valette wrote:
> Andrew,
> 
> The Changelog says nothing really important but forcing REGPARAM is 
> rather important : it breaks any external module using object only code 
> that calls a kernel function.
>...
> Complete stack trace attached... (that shows they do not expect kmalloc 
> to fail :-( )


-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr




[-- Attachment #2: bewanBub.txt --]
[-- Type: text/plain, Size: 4324 bytes --]

May  5 12:04:29 localhost kernel: unicorn_pci_atm: module license 'Proprietary' taints kernel.
May  5 12:04:29 localhost kernel: PCI: Enabling device 0000:00:09.0 (0014 -> 0016)
May  5 12:04:29 localhost kernel: unicorn_pci: AFE 70134
May  5 12:04:29 localhost kernel: unicorn_pci: v 0.0.0, 12:03:15 May  5 2004
May  5 12:04:29 localhost kernel: unicorn_pci: MSW parameters: 
May  5 12:04:29 localhost kernel: ActivationMode=1
May  5 12:04:29 localhost kernel: ActTimeout=300000
May  5 12:04:29 localhost kernel: AutoActivation=1
May  5 12:04:29 localhost kernel: DebugLevel=0
May  5 12:04:29 localhost kernel: DownstreamRate=8128
May  5 12:04:29 localhost kernel: unicorn_pci: ExchangeDelay=20
May  5 12:04:29 localhost kernel: FmPollingRate=1000
May  5 12:04:29 localhost kernel: g_RefGain=28
May  5 12:04:29 localhost kernel: g_Teqmode=7
May  5 12:04:29 localhost kernel: InitTimeout=20000
May  5 12:04:29 localhost kernel: Interoperability=0
May  5 12:04:29 localhost kernel: unicorn_pci: LCD_Trig=15000
May  5 12:04:29 localhost kernel: LOS_LOF_Trig=5000
May  5 12:04:29 localhost kernel: LoopbackMode=0
May  5 12:04:29 localhost kernel: MswDebugLevel=2
May  5 12:04:29 localhost kernel: RetryTime=5000
May  5 12:04:29 localhost kernel: TrainingDelay=120
May  5 12:04:29 localhost kernel: unicorn_pci: useRFC019v=0
May  5 12:04:29 localhost kernel: useRFC029v=7000
May  5 12:04:29 localhost kernel: useRFC040v=0
May  5 12:04:29 localhost kernel: useRFC041v=1
May  5 12:04:29 localhost kernel: setINITIALDAC=93
May  5 12:04:29 localhost kernel: unicorn_pci: useRFCFixedRate=1
May  5 12:04:29 localhost kernel: useVCXO=0
May  5 12:04:29 localhost kernel: _no_TS652=0
May  5 12:04:29 localhost kernel: unicorn_pci: driver parameters: DebugLevel=0
May  5 12:04:29 localhost kernel: alloc_obj: kmalloc failed,size=-742088876,type=abc0
May  5 12:04:29 localhost kernel:  printing eip:
May  5 12:04:29 localhost kernel: e3aa11d5
May  5 12:04:29 localhost kernel: Oops: 0002 [#1]
May  5 12:04:29 localhost kernel: PREEMPT 
May  5 12:04:29 localhost kernel: CPU:    0
May  5 12:04:29 localhost kernel: EIP:    0060:[pg0+592122325/1067507712]    Tainted: P   VLI
May  5 12:04:29 localhost kernel: EFLAGS: 00010296   (2.6.6-rc3-mm2) 
May  5 12:04:29 localhost kernel: EIP is at xsm_ident+0x15/0xf0 [unicorn_pci_atm]
May  5 12:04:29 localhost kernel: eax: 00000001   ebx: 00000000   ecx: 00000001   edx: 00000001
May  5 12:04:29 localhost kernel: esi: 00000000   edi: e3ae6b00   ebp: 00000001   esp: d3c49ecc
May  5 12:04:29 localhost kernel: ds: 007b   es: 007b   ss: 0068
May  5 12:04:29 localhost kernel: Process modprobe (pid: 3217, threadinfo=d3c49000 task=d6ba11f0)
May  5 12:04:29 localhost kernel: Stack: 00000000 0000abc0 d3c49f54 e3aa072b 00000001 00000001 00000000 00000000 
May  5 12:04:29 localhost kernel:        e3ae6b00 d3c49f10 e3a86a67 e3ab313f 00000000 00000000 e3aa8f20 00000000 
May  5 12:04:29 localhost kernel:        00000000 d3c49f50 e3a60d7c 00000000 d3c49f44 000000ff 00000000 de618768 
May  5 12:04:29 localhost kernel: Call Trace:
May  5 12:04:29 localhost kernel:  [pg0+592119595/1067507712] alloc_obj+0xfb/0x130 [unicorn_pci_atm]
May  5 12:04:29 localhost kernel:  [pg0+592013927/1067507712] _ZN19InterfaceProtectionC1Ev+0x17/0x48 [unicorn_pci_atm]
May  5 12:04:29 localhost kernel:  [pg0+591859068/1067507712] AMSW_Modem_SW_Init+0x28/0x11c [unicorn_pci_atm]
May  5 12:04:29 localhost kernel:  [pg0+592133283/1067507712] unicorn_atm_startdevice+0x23/0x90 [unicorn_pci_atm]
May  5 12:04:29 localhost kernel:  [pg0+592128052/1067507712] msw_init+0x14/0x140 [unicorn_pci_atm]
May  5 12:04:29 localhost kernel:  [pg0+592142941/1067507712] unicorn_attach+0x16d/0x1b0 [unicorn_pci_atm]
May  5 12:04:29 localhost kernel:  [pg0+592429885/1067507712] unicorn_pci_init+0x33d/0x43e [unicorn_pci_atm]
May  5 12:04:29 localhost kernel:  [sys_init_module+258/528] sys_init_module+0x102/0x210
May  5 12:04:29 localhost kernel:  [filp_close+79/128] filp_close+0x4f/0x80
May  5 12:04:29 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
May  5 12:04:29 localhost kernel: 
May  5 12:04:29 localhost kernel: Code: c0 8b 44 24 30 c7 00 00 00 00 00 b8 01 00 00 00 eb b1 8d 74 26 00 55 89 cd 57 56 53 83 ec 18 89 44 24 14 c7 44 24 10 01 00 00 00 <c7> 01 00 00 00 00 9c 5b fa b8 00 f0 ff ff 21 e0 ff 40 14 a1 bc 

Re: RE : 2.6.6-rc3-mm2 : REGPARAM forced => no external module with some object code only

[Andrew Morton]

Eric Valette <eric.valette@free.fr> wrote:
>
> The Changelog says nothing really important but forcing REGPARAM is 
>  rather important : it breaks any external module using object only code 
>  that calls a kernel function.

This is why we should remove the option - to reduce the number of ways in
which the kernel might have been built.  Yes, there will be a bit of
transition pain while these people catch up.

Re: RE : 2.6.6-rc3-mm2 : REGPARAM forced => no external module with some object code only

[Zephaniah E. Hull]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

On Wed, May 05, 2004 at 01:18:09PM -0700, Andrew Morton wrote:
> Eric Valette <eric.valette@free.fr> wrote:
> >
> > The Changelog says nothing really important but forcing REGPARAM is 
> >  rather important : it breaks any external module using object only code 
> >  that calls a kernel function.
> 
> This is why we should remove the option - to reduce the number of ways in
> which the kernel might have been built.  Yes, there will be a bit of
> transition pain while these people catch up.

Any guess on when REGPARAM and 4KSTACKS will end up in Linus' tree?
(Of interest because people may not consider it that important until
they know it really is going to bite them.)

-- 
	1024D/E65A7801 Zephaniah E. Hull <warp@babylon.d2dc.net>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

"Microsoft is a cross between the Borg and the Ferengi.  Unfortunately,
they use Borg to do their marketing and Ferengi to do their
programming."
  -- Simon Slavin in asr

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RE : 2.6.6-rc3-mm2 : REGPARAM forced => no external module with some object code only

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

On Thu, 2004-05-06 08:44:54 -0400, Zephaniah E. Hull <warp@babylon.d2dc.net>
wrote in message <20040506124454.GA12921@babylon.d2dc.net>:
> On Wed, May 05, 2004 at 01:18:09PM -0700, Andrew Morton wrote:
> > Eric Valette <eric.valette@free.fr> wrote:
> > >
> > > The Changelog says nothing really important but forcing REGPARAM is 
> > >  rather important : it breaks any external module using object only code 
> > >  that calls a kernel function.
> > 
> > This is why we should remove the option - to reduce the number of ways in
> > which the kernel might have been built.  Yes, there will be a bit of
> > transition pain while these people catch up.

Sorry, missed the previous mail...

Well, practically, reducing options will help compatibility, *but*
personally, I don't see a problem there. Linux only claims limited
source compatibility, so I don't see much of a problem there. If binary
modules fall down to their feet, they need to catch up.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RE : 2.6.6-rc3-mm2 : REGPARAM forced => no external module with some object code only

[Eric Valette]

Zephaniah E. Hull wrote:
> On Wed, May 05, 2004 at 01:18:09PM -0700, Andrew Morton wrote:
> 
>>Eric Valette <eric.valette@free.fr> wrote:
>>
>>>The Changelog says nothing really important but forcing REGPARAM is 
>>> rather important : it breaks any external module using object only code 
>>> that calls a kernel function.
>>
>>This is why we should remove the option - to reduce the number of ways in
>>which the kernel might have been built.  Yes, there will be a bit of
>>transition pain while these people catch up.
> 
> 
> Any guess on when REGPARAM and 4KSTACKS will end up in Linus' tree?
> (Of interest because people may not consider it that important until
> they know it really is going to bite them.)

Well, may I suggest that the impact on end users is absolutely not the 
same :
	- 4KSTACKS only bites people that use badly written drivers allocating 
a lot of local variables on the stack (Nvidia, ...) and the availiable 
stack using this config is (from what I've read on this list) roughly 
equivalent to what is availiable in 2.4 series...
	- REGPARAM kills any driver whith object only file containing system calls,

Concerning the number of ways the kernel is compiled, I think that the 
number of GCC version produce even more debugging path than theses 
options. I really wonder if this is not a tactical game to push hardware 
manufacturer. But beware it could strike back because some supplier may 
just give up if they have to work on their driver even on stable series...


-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: RE : 2.6.6-rc3-mm2 : REGPARAM forced => no external module with some object code only

[Andrew Morton]

"Zephaniah E. Hull" <warp@mercury.d2dc.net> wrote:
>
> On Wed, May 05, 2004 at 01:18:09PM -0700, Andrew Morton wrote:
> > Eric Valette <eric.valette@free.fr> wrote:
> > >
> > > The Changelog says nothing really important but forcing REGPARAM is 
> > >  rather important : it breaks any external module using object only code 
> > >  that calls a kernel function.
> > 
> > This is why we should remove the option - to reduce the number of ways in
> > which the kernel might have been built.  Yes, there will be a bit of
> > transition pain while these people catch up.
> 
> Any guess on when REGPARAM and 4KSTACKS will end up in Linus' tree?

Tomorrow?  Linus will probably have some opinions on that, but if we're
going to do this thing we need to do it early in the cycle.

Re: RE : 2.6.6-rc3-mm2 : REGPARAM forced => no external module with some object code only

[Bill Davidsen]

Andrew Morton wrote:
> Eric Valette <eric.valette@free.fr> wrote:
> 
>>The Changelog says nothing really important but forcing REGPARAM is 
>> rather important : it breaks any external module using object only code 
>> that calls a kernel function.
> 
> 
> This is why we should remove the option - to reduce the number of ways in
> which the kernel might have been built.  Yes, there will be a bit of
> transition pain while these people catch up.

Yes, I think that should go into the 2.7 tree as soon as it opens. Of 
course it wouldn't go in the 2.6 tree, that's stable, right?


-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979