No luck, I'm afraid.
I put the modem in a PCI slot that was sharing IRQ only with the PATA
conroller. I then disabled the PATA controller in the BIOS, so the modem
was the only device on that IRQ. No luck- it still responds slowly.
Regarding the 537 modem issue, the modem is from a Dell system, and is
marked 537EPG... which appears to be a variant of the 537 system-
perhaps the reason others are having problems with it.
For what it's worth, the chip says 'FA82537EP', '0448DGEA40', Intel '02
I can send photos of the board if necessary.
Best,
Bjorn.
Marvin Stodolsky wrote:
> RE extremely lazy but clever workaround (just add this preprocessor
> code right after the
> headers includes):
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,21)
> #define pci_find_device pci_get_device
> #endif
> -------------
> Thanks Philippe, will do tonight.
>
> MarvS
>
> On Wed, Jul 8, 2009 at 12:27 PM, Philippe
> Vouters<Philippe.Vouters@xxxxxxxxxxx> wrote:
>> Dear Antonio,
>>
>> The .c code looks to essentially be acting as the code I added to
>> workaround the kernel's 8250_pci.c code issue for the Intel 537 modem
>> boards.
>>
>> Here is the relevant code part I recently added (in coredrv/coredrv.c)
>> "
>> int softcore_init_struct(struct softcore_struct* s)
>> {
>> register struct pci_dev *pdev;
>> if ((pdev=get_pci_info(s)) == NULL){
>> #ifdef DEBUG_LINUX
>> printk(KERN_ERR"%s:softcore: get_pci_info failed. Returning -1\n",
>> SOFTSERIAL_DEVICE_NAME);
>> #endif
>> return -ENODEV;
>> }
>> if (pdev->driver)
>> {
>> printk(KERN_ERR"%s:softcore_init_struct: driver %s already
>> allocated devi
>> ce.\n",
>> SOFTSERIAL_DEVICE_NAME,
>> dev_driver_string(&pdev->dev));
>> if (!strcmp(dev_driver_string(&pdev->dev),"serial"))
>> {
>> printk(KERN_WARNING"%s:softcore_init_struct: Unregistering %s
>> driver.
>> \n",
>> SOFTSERIAL_DEVICE_NAME,
>> dev_driver_string(&pdev->dev));
>> pci_unregister_driver(pdev->driver);
>> }
>> else
>> return -ENODEV;
>> }
>> #ifdef DEBUG_LINUX
>> else
>> {
>> printk (KERN_INFO"%s:softcore_init_struct: pdev->driver is NULL\n",
>> SOFTSERIAL_DEVICE_NAME);
>> }
>> #endif
>> "
>> Note that the pci_find_device call used in the
>> ungrab-winmodem-20080126/ungrab-winmodem.c code is currently obsoleted
>> and produces a compile-time warning since some kernels back. The very
>> simplest way to have the code very up to date with a clean compilation
>> under many kernels is to use the following bastard, extremely lazy but
>> clever workaround (just add this preprocessor code right after the
>> headers includes):
>> "
>> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,21)
>> #define pci_find_device pci_get_device
>> #endif
>> "
>> The kind of code you sent me and my above code are just workarounds to
>> unintentional mistakes in the Linux kernel. The actual correction ought
>> to be performed by the Linux kernel guys. Concerning the 537 driver
>> interaction with the serial driver, the 8250_pci.c code ought to really
>> blacklist the Winmodems he inadvertently recognizes and fails to
>> correctly handle. This is quite understandable as this part of the Linux
>> kernel has never been designed to handle proprietary closed source code.
>> This is definitely not Linux spirit.
>>
>> Yours very sincerely,
>> -
>> http://vouters.dyndns.org:8080/
>> Philippe Vouters (Fontainebleau/France)
>>
>>
>> Le mercredi 08 juillet 2009 à 09:47 -0500, Antonio Olivares a écrit :
>>> Phillipe,
>>>
>>> This makes me wonder about the ungrab-windmodem that is used in
>>> smartlink modems. Could users that are encountering this problem try
>>> it out here and see if it helps them resolve this issue?
>>>
>>> http://linmodems.technion.ac.il/packages/smartlink/ungrab-winmodem-20080126.tar.gz
>>>
>>> I have seen the serial driver try to claim the spot on PCTEL 789
>>> Chipset, and of course it does grab it with smartlink modems, but the
>>> ungrab-winmodem is designed for that. In the pctel modem, it does not
>>> affect a connection, I can still connect, but not under kernels >=
>>> 2.6.30, and thanks to your new driver I am using the Intel 536 modem
>>> without any problems.
>>>
>>> Just a thought, it might help here.
>>>
>>> Regards,
>>>
>>> Antonio
>>>
>>> On 7/8/09, Philippe Vouters <Philippe.Vouters@xxxxxxxxxxx> wrote:
>>>> Hi Bjorn,
>>>>
>>>> If you carefully read the lspci information you just sent me, your 537
>>>> board suffers from the exact same odd problem as the two 537 modem
>>>> owners (in Ireland and in India). You can read in your data this line:
>>>>
>>>> Kernel driver in use: serial
>>>>
>>>> The "serial" driver is nothing but the 8250_pci.c kernel code, which
>>>> conflicted with the 537 driver. This is something I did rule out in my
>>>> latest 536EP/537EP code. As of today, this "serial" driver gets
>>>> unregistered by the 537 driver.
>>>>
>>>> You do get this above information because your 537 board is a
>>>> "Communication controller" and has exactly one or zero memory region and
>>>> one I/O region. The 536EP board has exactly one memory region and zero
>>>> I/O region, hence the 8250_pci.c code not thinking he has to handle the
>>>> board.
>>>>
>>>> The 8250_pci.c kernel code does lack blacklisting many Winmodems boards.
>>>> It just blacklists the AC'97 ALI modem which happens to be also handled
>>>> by 537 driver.
>>>>
>>>> Yours truly,
>>>> -
>>>> http://vouters.dyndns.org:8080/
>>>> Philippe Vouters (Fontainebleau/France)
>>>>
>>>>
>>>> Le mardi 07 juillet 2009 à 18:54 -0300, Bjorn Wielens a écrit :
>>>>> Kernel driver in use: serial
>>>>
>>>>
>>
>>
>
Attachment:
signature.asc
Description: PGP signature
Attachment:
signature.asc
Description: OpenPGP digital signature
