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 same 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 it. 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

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

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.

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.