Dear folks,
I cc:'d to the wrong list. Thanks to Jacques for pointing this out:
discuss@xxxxxxxxxxxxx two lls instead of linmodems.org
Gmail's fault though.and me overlooking it too :(
Yair has explained the situation about the SLEEPING function.
Regards,
Antonio
---------- Forwarded message ----------
From: Antonio Olivares <olivares14031@xxxxxxxxx>
Date: Sun, 11 Apr 2010 13:48:35 -0500
Subject: Re: ungrab-winmodem, BUG: sleeping function called from
invalid context at include/linux/kernel.h:158
To: Yair Elharrar <freezer.spam@xxxxxxxxx>
Cc: Marvin Stodolsky <marvin.stodolsky@xxxxxxxxx>, discuss@xxxxxxxxxxxxx
Yair,
I am sure that I need ungrab-winmodem:
[olivares@localhost ~]$ dmesg | grep 'slamr'
slamr: module license 'Smart Link Ltd.' taints kernel.
slamr: SmartLink AMRMO modem.
slamr: probe 10b9:5459 SL1800 card...
slamr 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
slamr: mc97 codec is SIL26
slamr: slamr0 is SL1800 card.
[<fe2b32ca>] amrmo_read+0x50/0x66 [slamr]
[<fe2b327a>] ? amrmo_read+0x0/0x66 [slamr]
[olivares@localhost ~]$ dmesg | grep 'grab'
device 10b9:5459 is grabbed by driver serial: try to release
[olivares@localhost ~]$ uname -r
2.6.32.10-90.fc12.i686.PAE
For this part:
<quote>
As for the "sleeping function" message, the real problem is that IRQs
are disabled in this context (amrmo_read function). This could only be
caused by a logic error or stack overrun in the proprietary module,
amrlibs.o (for which we have no source code).
</quote>
Since it is a conditional thing, ie. has a condition while !(doing
anything) then SLEEPING, could we just let it not SLEEP?
I am thankful to Mr. Sam Sharpe who sent me the following to get the
sleeping function:
[olivares@localhost ~]$ tail -n +152 /usr/src/kernels/`uname
-r`/include/linux/kernel.h | head -n8
#ifdef CONFIG_PROVE_LOCKING
void might_fault(void);
#else
static inline void might_fault(void)
{
might_sleep();
}
I mean not go there to (might_sleep()) even though the modem may get
tired and want to go to sleep?
If it is because of the proprietary amrlibs.o, then we have to learn
with it and accept it for what it is.
BTW,
I hope that you don't mind I included your name in the page:
http://modemhelplinux.741.com/slmodemd-setup-1.html
For your contributions to getting the slmodem-2.9.11-20XY.tar.gz code
to work with newer kernels.
Thanks for your contributions and help.
Regards,
Antonio
On 4/11/10, Yair Elharrar <freezer.spam@xxxxxxxxx> wrote:
> Hi Antonio,
> Regarding ungrab-winmodem, I'm not sure I understand the purpose of
> this module - but the code looks as if it has been integrated into
> slamr at some point (amrmo_init performs the same function). Are you
> sure it is really required?
>
> As for the "sleeping function" message, the real problem is that IRQs
> are disabled in this context (amrmo_read function). This could only be
> caused by a logic error or stack overrun in the proprietary module,
> amrlibs.o (for which we have no source code). If you wish to verify
> this, add the following to amrmo_read just before the call to
> copy_to_user:
>
>
> 2010/4/11 Antonio Olivares <olivares14031@xxxxxxxxx>:
>> Dear folks,
>>
>> I have successfully used Smartlink modems since 2003/2004 and have
>> been through ups and downs, most recently the code was not working
>> with 2.6.31 kernels and now thanks to Yair and his work we have
>> working slmodemd. Still we have problems with ungrab-winmodem, since
>> kernel 2.6.10/11 till the present we have needed the patch to make it
>> work, because the kernel serial driver grabs it and thinks that it
>> will support it?
>>
>> To find the changes one might need to take a look at what changed from
>> 2.6.9, 2.6.10, and 2.6.11 and see the changes made there and find out
>> ultimately what made the difference?
>>
>> Also, I enounter this bug many times, it appears to be harmless, but
>> nonetheless appears:
>>
>> BUG: sleeping function called from invalid context at
>> include/linux/kernel.h:158
>> in_atomic(): 0, irqs_disabled(): 1, pid: 9713, name: slmodemd
>> Pid: 9713, comm: slmodemd Tainted: P 2.6.32.10-90.fc12.i686.PAE
>> #1
>> Call Trace:
>> [<c043372f>] __might_sleep+0xca/0xd1
>> [<c05c6c3a>] might_fault+0x19/0x20
>> [<c05c6d8e>] copy_to_user+0x34/0x10a
>> [<fe2b32ca>] amrmo_read+0x50/0x66 [slamr]
>> [<fe2b327a>] ? amrmo_read+0x0/0x66 [slamr]
>> [<c04e15fc>] vfs_read+0x82/0xe1
>> [<c04e9d17>] ? path_put+0x1a/0x1d
>> [<c04e16f9>] sys_read+0x40/0x62
>> [<c040907b>] sysenter_do_call+0x12/0x28
>>
>>
>> I asked on the Fedora users list (users@xxxxxxxxxxxxxxxxxxxxxxx ), and
>> thanks to Sam Sharpe, now we know what is in that line:
>>
>> <quote>
>> On 10 April 2010 21:29, Antonio Olivares <olivares14031@xxxxxxxxx> wrote:
>>> Dear folks,
>>>
>>> I have encountered this so called sleeping function several times in a
>>> good while
>>> (kernel 2.6.27, 2.6.29, 2.6.30, 2.6.31, 2.6.32) Fedora based kernels and
>>> compiled
>>> kernels from kernel.org,
>>>
>>> I am asking this because I see this again and again. I would like to
>>> know what is
>>> in there so if I can do something about it, or just live with it since it
>>> appears to be
>>> harmless, but anyhow it is annoying :(
>>
>> [sam@samlap ~ ]$ tail -n +152 /usr/src/kernels/`uname
>> -r`/include/linux/kernel.h | head -n8
>> #ifdef CONFIG_PROVE_LOCKING
>> void might_fault(void);
>> #else
>> static inline void might_fault(void)
>> {
>> might_sleep();
>> }
>> #endif
>>
>> --
>> Sam
>> </quote>
>>
>> Is there anyway that we can avoid SLEEPING in the slmodemd code to not
>> see this so called oops?
>>
>> For the other problem, Might disabling the serial driver cause us not
>> to need ungrab-winmodem?
>> I am used to ungrab-winmodem and I like it very much it has given
>> me/us slmodemd users a way to use our computers and connect. But how
>> come nothing has been done upstream with kernel developers? It would
>> be nice that they fix the issue up there. Still a thought.
>>
>> Regards,
>>
>> Antonio
>>
>
