M. Koehrer wrote: > Hi Jan, > > I have actually identified the difference and made a patch against the > rt_eepro100.c. > Using this patch my setup is running fine now!!!! > I do not understand in detail what is happening as it seems to be important > to read > the status register more than once under some circumstances... > Anyway, enclosed is the patch. Perhaps as many people as possible can test it > and see > if there are some issues that came in by this patch.
A bit hard to comment on the patch as it went to the list as octet
stream. Anyway, here is a copy:
> --- rtnet-0.9.6/drivers/rt_eepro100.c.orig Fri Oct 20 12:35:44 2006
> +++ rtnet-0.9.6/drivers/rt_eepro100.c Fri Oct 20 13:03:48 2006
> @@ -382,6 +382,7 @@
> All accesses need not be longword aligned. */
> enum speedo_offsets {
> SCBStatus = 0, SCBCmd = 2, /* Rx/Command Unit command and status.
> */
> + SCBIntmask = 3,
> SCBPointer = 4, /* General purpose pointer. */
> SCBPort = 8, /* Misc. commands and operands.
> */
> SCBflash = 12, SCBeeprom = 14, /* EEPROM and flash memory control. */
> @@ -1647,7 +1648,21 @@
> rtdev->name, status);
>
> if ((status & 0xfc00) == 0)
> - break;
> + goto irq_out;
This jump-out appears bogus to me. You are skipping code that the
previous approach included.
> +
> + {
> + /* Disable interrupts at the hardware by setting the M (mask) bit
> + * in the adapter's CSR SCB command word.
> + * It also clear/ack interrupts.
> + * See: e100 driver
> + * */
> + unsigned short intr_status;
> +
> + outb(1, ioaddr + SCBIntmask);
> + intr_status = inw(ioaddr + SCBStatus);
> + outw(intr_status, ioaddr + SCBStatus);
> + inw(ioaddr + SCBStatus);
> + }
>
> /* Always check if all rx buffers are allocated. --SAW */
> speedo_refill_rx_buffers(rtdev, 0);
> @@ -1744,7 +1759,8 @@
> outw(0xfc00, ioaddr + SCBStatus);
> break;
> }
> - } while (1);
> + }
> + while (0);
Is this intended? You no longer iterate over succeeding events now. That
explains the jump-out above, but it still looks strange.
>
> if (speedo_debug > 3)
> rtdm_printk(KERN_DEBUG "%s: exiting interrupt,
> status=%#4.4x.\n",
> @@ -1753,6 +1769,16 @@
> clear_bit(0, (void*)&sp->in_interrupt);
> if (packets > 0)
> rt_mark_stack_mgr(rtdev);
> +
> + {
> + /* Sets interrupts at the hardware by resetting
> + * the M (mask) bit in the adapter's CSR SCB command word
> + * */
> + outb(0, ioaddr + SCBIntmask);
> + inw(ioaddr + SCBStatus);
Does this melt down to clearing the "M bit" (global IRQ mask?) of the
controller as long as in IRQ context? I don't see where this happen in
e100 (Intel's version 3.5.14). This seems to be the NAPI polling path
(and that's BTW a reason to NOT follow the kernel's e100 as it only
knows NAPI - baaaad for RT).
> +
> + }
> +irq_out:
> return RTDM_IRQ_HANDLED;
> }
>
As I still have no luck in reproducing your problem here, could you try
to narrow down the magic code that makes it work? I would e.g. be keen
on knowing if playing with the IRQ mask of the e100 does the trick or if
it is the access to the status register and the acknowledge code.
eepro100 applies some mask on the status, e100 and your patch obviously
not. Or is it the non-iterating approach, i.e. to handle only one RX
event per IRQ?
Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
