While not erudite in the code details, my memory of the
ungrab-winmodem history is the follows.
With kernel 2.6.10, there was some change in the kernel-source code,
which is some way blocked slamr from creating/using its /dev/slamr0
port. Maintainer Sasha did file a complaint with the kernel-source
team. But for the short term he wrote the ungrab-winmodem driver,
which removed the blockage. Since then it has been necessary to load
ungrab-winmodem before slamr,
but with some hope that ungrab-winmodem function would at sometime be
obviated by a change in the kernel-source.
MarvS
On Sun, Apr 11, 2010 at 3:09 PM, Yair Elharrar <freezer.spam@xxxxxxxxx> wrote:
> Antonio,
> I see now that the code in amrmo_init is disabled by #if
> LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10). That might explain why it
> doesn't work.
>
> As for the "sleeping" issue - might_fault() is a safety check, it is
> there to ensure that copy_to_user (and many other functions) is not
> called while IRQs are disabled. The problem is not that copy_to_user
> is "sleeping" - the problem is that amrmo_card_read disabled IRQs and
> didn't properly restore them.
>
>
> On Sun, Apr 11, 2010 at 9:48 PM, Antonio Olivares
> <olivares14031@xxxxxxxxx> wrote:
>> 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
>>>>
>>>
>>
>
