Re: 536ep Slow to respond, openSuSE 11.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> >
> >
> >
> 



[Index of Archives]     [Linux Media Development]     [Asterisk]     [DCCP]     [Netdev]     [X.org]     [Xfree86]     [Fedora Women]     [Linux USB]

  Powered by Linux