Manual loading of skge and sky2 driver in the 2.4.26 based system

Discussion in 'Kernel Questions' started by tommyclee, Dec 7, 2008.

  1. tommyclee

    tommyclee New Member

    Hi all,

    About a week ago I completed the 2.4.36.7-to-2.4.26 back-porting work of these two drivers.

    This week I encountered an issue of manual-loading them in my 2.4.26/x86 system. This system has four 88E8001 chips and four 88E8053 chips for the skge and sky2 drivers to handle respectively. The scenario is that I have to load the drivers twice in order to use them normally.

    For example, my skge driver logging code shows that, in the first (initial) time
    loading, the PCI code displays the "PCI: Sharing IRQ..." messages of the IRQs 11, 12, 5, and 10. Right after pci_init_module() returns rc = 4, which is correct, the kernel code displays the "init_module: Device or resource busy" message. At the end the skge driver is not loaded.

    The second time succeeded in the loading of the skge driver with no display of the Sharing IRQ..." messages. The pci_init_module() returns rc = 0. I see this return value reasonable. After that, when I enable the eth0, the lsmod command shows 1 as the skge driver's use count. This interface is able to transport traffics normally.

    I compared the skge driver log against that of the old sk98lin driver in the sam
    e system. I discovered the display of the Sharing IRQ..." messages happen in the sh98lin driver loading as well in my system. This comparison indicates that the IRQ and IO sharing is not the cause of the ""init_module: Device or resource busy" issue.

    I am finding out the reason why the kernel raises this issue in order to solve i
    t. I will definitely be grateful for your comment on this issue. If you need the
    details of it, I will be happy to provide.

    Tommy
     
  2. tommyclee

    tommyclee New Member

    Hi all,

    Referring to the skge driver code in the 2.6.21.7 kernel, which I worked on the same driver about a month ago, I replaced the 2.4.26 request_irq() SA_SHIRQ|SA_SAMPLE_RANDOM flag with the IRQF_SHARED (0x00000080) one, which is not defined in the 2.4.26 kernel. This time, though the "init_module: Device or resource busy" message is still displayed by the 2.4.26 kernel, the IRQF_SHARED flag at least links the devices to their IRQs correctly as shows by the "cat /proc/interrupts" command:

    bash-2.05b# cat /proc/interrupts
    CPU0
    0: 18488 XT-PIC timer
    2: 0 XT-PIC cascade
    4: 713 XT-PIC serial
    5: 0 XT-PIC eth2
    8: 3 XT-PIC rtc
    10: 0 XT-PIC eth3
    11: 0 XT-PIC eth0
    12: 0 XT-PIC eth1
    14: 13447 XT-PIC ide0
    NMI: 0
    ERR: 0

    My next step is to make the similar change in the sky2 driver to try to make the 11, 12, 5, 10 IRQs correctly shared around, after loading the two drivers. If I can accomplish this step, my problem space will be narrowed down the 2.4.26 kernel displaying the "init_module..." message.

    Comment please

    Tommy
     
  3. tommyclee

    tommyclee New Member

    I succeeded in the loading of these two drivers in my 2.4.26/x86 system. The drivers could be loaded either at-boot-time or manually. The solutions include:

    Using the 2.6.21.7 pci_init_module code in place of the 2.4.26 one.
    Using SA_SHIRQ as the only flag on the 2nd parameter of calling request_irq().

    Unfortunately, the "init_module: Device or resource busy" message is still displayed by the 2.4.26 kernel. But it could be worked around by twice-loading of the drivers.
     
  4. tommyclee

    tommyclee New Member

    I just solved the skge/sky2 "init_module: device or resource busy" problem in my 2.4.26/x86 system. The problem occurred when either driver was loaded the first time. The second loading was the workaround. The solution to this problem is to return zero from the driver initialization code, instead of the number of the interfaces which were claimed by the PCI driver registration function. The issue is that the 2.4.26 kernel PCI code causes this problem when it receives this non-zero number.

    I checked the sk98lin driver code in the 2.4.26 and 2.4.36.7 kernels. The sk98lin driver in either one does not use the above PCI code and go through its initialization process successfully. I also checked the skge and sk98lin driver codes in the 2.6.21.7 kernel. These two drivers do use the above PCI code and succeed in their initialization process. I suppose there must be a reason for the sk98lin driver in the 2.4 kernels by-passes the PCI code; the back-ported drivers should avoid it as well.

    With the skge and sky2 drivers one-time loaded in my system, I have verified their interface enabling/disabling, packet sending/receiving and module loading/unloading functionalities. I do not encountered any problems.
    :)
     
  5. tommyclee

    tommyclee New Member

    I am able to login. Why I need to become a susbcriber in order to suuport HowToForge? I hope you would answer my question.
     
  6. falko

    falko Super Moderator

    I'm sorry, but I don't know the answer for every problem; especially your problem is very special. The other forum users probably didn't know a solution either, that's why you got no answer. That's not meant personally.
     

Share This Page