gmane.comp.embedded.neuros.dm320

chrispe | 6 Mar 16:51

PATCH dm9ks interrupt handling


I was having problems with the OSD not receiving packets on a busy
network. Typically I would notice this when a telnet session hung for
5-15 seconds when I pressed a key, but it also happened in many other
circumstances.

I discovered that the driver had some code that disabled the receive
interrupt after 10 packets were received. The interrupt would be re-
enabled by completing a transmit or by a 5 second timer. This somewhat
crazy code was presumably designed to reduce the load on the processor
(or maybe the IRQ system) when the device is not actively
communicating. However, on a network with a moderate amount of
broadcast traffic it was very common for the device to stop receiving
for several seconds and then overrun its receive buffer when the
interrupt was re-enabled.

I have removed this mechanism and also removed the bogus ioctl handler
that just returned success to all calls, which makes things like the
mii interface look like they work, but always return junk!

Patch below.

Chris.

--- dm9ks.c.orig	2007-03-06 15:10:23.000000000 +0000
+++ dm9ks.c	2007-03-06 15:15:16.000000000 +0000
@@ -37,6 +37,8 @@
 V2.03	11/22/2005	Power-off and Power-on PHY in dmfe_init()
 			support IOL
 06/17/2006	Butchered for NTR3 OSD

(Continue reading)

headers

Nathan Crawford | 6 Mar 18:08

Re: PATCH dm9ks interrupt handling


--- chrispe <chris <at> edesix.com> wrote:

> 
> I was having problems with the OSD not receiving packets on a
> busy
> network. Typically I would notice this when a telnet session
> hung for
> 5-15 seconds when I pressed a key, but it also happened in
> many other
> circumstances.
> 
> I discovered that the driver had some code that disabled the
> receive
> interrupt after 10 packets were received. The interrupt would
> be re-
> enabled by completing a transmit or by a 5 second timer. This
> somewhat
> crazy code was presumably designed to reduce the load on the
> processor
> (or maybe the IRQ system) when the device is not actively
> communicating. However, on a network with a moderate amount of
> broadcast traffic it was very common for the device to stop
> receiving
> for several seconds and then overrun its receive buffer when
> the
> interrupt was re-enabled.
> 
> I have removed this mechanism and also removed the bogus ioctl
> handler

(Continue reading)

headers

Dan Fandrich | 6 Mar 18:28

Re: PATCH dm9ks interrupt handling


On Tue, Mar 06, 2007 at 07:51:50AM -0800, chrispe wrote:
> I was having problems with the OSD not receiving packets on a busy
> network. Typically I would notice this when a telnet session hung for
> 5-15 seconds when I pressed a key, but it also happened in many other
> circumstances.

I've noticed exactly the same problem with my telnet sessions.

> I discovered that the driver had some code that disabled the receive
> interrupt after 10 packets were received. The interrupt would be re-
> enabled by completing a transmit or by a 5 second timer. This somewhat
> crazy code was presumably designed to reduce the load on the processor
> (or maybe the IRQ system) when the device is not actively
> communicating. However, on a network with a moderate amount of
> broadcast traffic it was very common for the device to stop receiving
> for several seconds and then overrun its receive buffer when the
> interrupt was re-enabled.

Crazy is right!  I'd be very curious to hear what the rationale was for
that.  

> I have removed this mechanism and also removed the bogus ioctl handler
> that just returned success to all calls, which makes things like the
> mii interface look like they work, but always return junk!

Sounds like more crazyness to me.  Maybe that was someone's brilliant
solution to get rid of an "ioctl not supported" message somewhere.
I'm all for these patches.

(Continue reading)

headers

sourcerror | 7 Mar 09:04

Re: PATCH dm9ks interrupt handling

On Mar 6, 9:28 am, Dan Fandrich <d...@coneharvesters.com> wrote:
> On Tue, Mar 06, 2007 at 07:51:50AM -0800, chrispe wrote:
> > I was having problems with the OSD not receiving packets on a busy
> > network. Typically I would notice this when a telnet session hung for
> > 5-15 seconds when I pressed a key, but it also happened in many other
> > circumstances.
>
> I've noticed exactly the same problem with my telnet sessions.

Yow.  I saw (I think) the same symptoms in telnet when I first put my
OSD on the network.  At first I thought there was an IP address
collision.  I ruled that out but the hanging continued.  I was
wondering if it was agravated by some other stuff on the network like
maybe my TiVo which I think does some periodic broadcast/rendezvous
messages.

Anyway, I had no clue and finally put the OSD all by itself on a
subnet behind my 2nd network card. which was just a workaround.

headers

Terry Qiu | 7 Mar 09:29

Re: PATCH dm9ks interrupt handling


On Wed, 2007-03-07 at 08:04 +0000, sourcerror wrote:
> On Mar 6, 9:28 am, Dan Fandrich <d...@coneharvesters.com> wrote:
> > On Tue, Mar 06, 2007 at 07:51:50AM -0800, chrispe wrote:
> > > I was having problems with the OSD not receiving packets on a busy
> > > network. Typically I would notice this when a telnet session hung for
> > > 5-15 seconds when I pressed a key, but it also happened in many other
> > > circumstances.
> >
> > I've noticed exactly the same problem with my telnet sessions.
> 
> Yow.  I saw (I think) the same symptoms in telnet when I first put my
> OSD on the network.  At first I thought there was an IP address
> collision.  I ruled that out but the hanging continued.  I was
> wondering if it was agravated by some other stuff on the network like
> maybe my TiVo which I think does some periodic broadcast/rendezvous
> messages.
> 
> Anyway, I had no clue and finally put the OSD all by itself on a
> subnet behind my 2nd network card. which was just a workaround.
> 

Can you guys send me your console output when your OSD boot up? 

thanks

/tqiu

headers

Michael Gao | 6 Mar 21:23

Re: PATCH dm9ks interrupt handling


Chris, thanks for the patch, please see comment below.

Terry, please share your input on this.

On Tue, 2007-03-06 at 07:51 -0800, chrispe wrote:
> I was having problems with the OSD not receiving packets on a busy
> network. Typically I would notice this when a telnet session hung for
> 5-15 seconds when I pressed a key, but it also happened in many other
> circumstances.
> 
> I discovered that the driver had some code that disabled the receive
> interrupt after 10 packets were received. The interrupt would be re-
> enabled by completing a transmit or by a 5 second timer. This somewhat
> crazy code was presumably designed to reduce the load on the processor
> (or maybe the IRQ system) when the device is not actively
> communicating. However, on a network with a moderate amount of
> broadcast traffic it was very common for the device to stop receiving
> for several seconds and then overrun its receive buffer when the
> interrupt was re-enabled.
5 second timer seems crazy to me too. However if we remove it
completely, this may bring us a situation where the interrupt is held
too long?

Would an approach like the following work better?

"if the number of receive packet > LIMIT, exit the interrupt handler
with Ethernet interrupt enabled.", please see blow code portion comment.

>

(Continue reading)

headers

Anders Gustafsson | 7 Mar 15:57

Re: PATCH dm9ks interrupt handling

Michael Gao wrote:
> 5 second timer seems crazy to me too. However if we remove it
> completely, this may bring us a situation where the interrupt is held
> too long?

I checked the original davicom driver
(http://www.davicom.com.tw/eng/download/Driver/driver_9000a.htm) it also
has this disable interrupts after X consecutive rx packets without tx
thing.

It smells quite a bit like a workaround for some hardware bug to me. But
it could be something different it tries to solve; or just a clueless
engineer implementing the driver :)

I'd really like to know why that code is there, and what purpose it has.

(as a side note the changes from the original davicom driver "06/17/2006
    Butchered for NTR3 OSD" are quite big and messy)

Are there documentation for this NIC available btw?

>> I have removed this mechanism and also removed the bogus ioctl handler
>> that just returned success to all calls, which makes things like the
>> mii interface look like they work, but always return junk!
>>
> MG: Not sure about this, do we need this stub for driver compatibility
> purpose? thus not getting NULL pointer if somewhere upper layer will
> ever call the ioctl?

(Continue reading)

headers

chrispe | 8 Mar 01:10

Re: PATCH dm9ks interrupt handling

On Mar 7, 2:57 pm, Anders Gustafsson <ande...@0x63.nu> wrote:
> I'd really like to know why that code is there, and what purpose it has.

I think the DM9000A (which has a PC-card like interface) that this
driver was written for has the same core as the vanilla DM9000 (ISA),
which has a driver (dm9000.c) in the mainline kernel. The mainline
driver has none of the dubious code.

> (as a side note the changes from the original davicom driver "06/17/2006
>     Butchered for NTR3 OSD" are quite big and messy)

If I had the time to do the "right thing", I would discard the dm9ks
driver from Davicom (circa 2005) and enhance the mainline dm9000 ISA
driver (ironically also written by Davicom, circa 2003) to support the
DM9000A.

> Are there documentation for this NIC available btw?

Yes.

Chris.

headers

Terry Qiu | 8 Mar 07:14

Re: PATCH dm9ks interrupt handling


I have sent a mail to DAVICOM about this, will let you know what we got.

regards

/tqiu

On Wed, 2007-03-07 at 15:57 +0100, Anders Gustafsson wrote:
> Michael Gao wrote:
> > 5 second timer seems crazy to me too. However if we remove it
> > completely, this may bring us a situation where the interrupt is held
> > too long?
> 
> I checked the original davicom driver
> (http://www.davicom.com.tw/eng/download/Driver/driver_9000a.htm) it also
> has this disable interrupts after X consecutive rx packets without tx
> thing.
> 
> It smells quite a bit like a workaround for some hardware bug to me. But
> it could be something different it tries to solve; or just a clueless
> engineer implementing the driver :)
> 
> I'd really like to know why that code is there, and what purpose it has.
> 
> (as a side note the changes from the original davicom driver "06/17/2006
>     Butchered for NTR3 OSD" are quite big and messy)
> 
> Are there documentation for this NIC available btw?
> 
> >> I have removed this mechanism and also removed the bogus ioctl handler

(Continue reading)

headers

Terry Qiu | 15 Mar 08:27

Re: PATCH dm9ks interrupt handling

I just got the new driver for the dm9ks from vendor. 

I quick look through it, it seems fix this problem. But they don't clean
out the code about the CONT_RX_PKT_CNT and the timer. 
They now set the CONT_RX_PKT_CNT=0xFFFF and set the
db->cont_rx_pkt_cnt=0 first in  dmfe_packet_receive() 

I will merge it into OSD, if any of you want to see the original code
from vendor, The attachment is.

regards

/tqiu

On Thu, 2007-03-08 at 14:14 +0800, Terry Qiu wrote:
> I have sent a mail to DAVICOM about this, will let you know what we got.
> 
> regards
> 
> /tqiu
> 
> On Wed, 2007-03-07 at 15:57 +0100, Anders Gustafsson wrote:
> > Michael Gao wrote:
> > > 5 second timer seems crazy to me too. However if we remove it
> > > completely, this may bring us a situation where the interrupt is held
> > > too long?
> > 
> > I checked the original davicom driver
> > (http://www.davicom.com.tw/eng/download/Driver/driver_9000a.htm) it also

(Continue reading)

headers

Terry Qiu | 15 Mar 08:28

Re: PATCH dm9ks interrupt handling

Sorry, add attachment.
On Thu, 2007-03-15 at 15:27 +0800, Terry Qiu wrote:
> I just got the new driver for the dm9ks from vendor. 
> 
> I quick look through it, it seems fix this problem. But they don't clean
> out the code about the CONT_RX_PKT_CNT and the timer. 
> They now set the CONT_RX_PKT_CNT=0xFFFF and set the
> db->cont_rx_pkt_cnt=0 first in  dmfe_packet_receive() 
> 
> I will merge it into OSD, if any of you want to see the original code
> from vendor, The attachment is.
> 
> regards
> 
> /tqiu
> 
> On Thu, 2007-03-08 at 14:14 +0800, Terry Qiu wrote:
> > I have sent a mail to DAVICOM about this, will let you know what we got.
> > 
> > regards
> > 
> > /tqiu
> > 
> > On Wed, 2007-03-07 at 15:57 +0100, Anders Gustafsson wrote:
> > > Michael Gao wrote:
> > > > 5 second timer seems crazy to me too. However if we remove it
> > > > completely, this may bring us a situation where the interrupt is held
> > > > too long?
> > > 
> > > I checked the original davicom driver

(Continue reading)

headers

Michael Gao | 15 Mar 08:43

Re: PATCH dm9ks interrupt handling


On Thu, 2007-03-15 at 15:28 +0800, Terry Qiu wrote:
> > I quick look through it, it seems fix this problem. But they don't clean
> > out the code about the CONT_RX_PKT_CNT and the timer. 
> > They now set the CONT_RX_PKT_CNT=0xFFFF and set the
> > db->cont_rx_pkt_cnt=0 first in  dmfe_packet_receive() 
This basically takes the timer function out, when integrating, please
also manage to apply patch from Chris (completely remove timer, get rid
of the dummy stub), thanks.

/MG

headers

mgao | 8 Mar 05:45

Re: PATCH dm9ks interrupt handling

-----Original Message-----
> (as a side note the changes from the original davicom driver "06/17/2006
> Butchered for NTR3 OSD" are quite big and messy)

If I had the time to do the "right thing", I would discard the dm9ks
driver from Davicom (circa 2005) and enhance the mainline dm9000 ISA
driver (ironically also written by Davicom, circa 2003) to support the
DM9000A.

MG: One big part of the trouble (definitely not right yet, messy too?) is Ethernet DMA support. Currently the Ethernet packet receiving is directly handled by the ISR (which is why I am afraid taking out the packet limit check may cause holding the interrupt too long), thus DMA can not be fully supported without rewriting this part of the logic. The code today enables the DMA in the ISR but has to _wait_ till DMA is done, which is pretty pointless.

Does anyone have an idea of how this should be fixed?

--~--~---------~--~----~------------~-------~--~----~
FOR REALTIME DISCUSSION GO TO IRC #neuros on freenode

You received this message because you are subscribed to the Google Groups "Neuros-DM320" group.
To post to this group, send email to Neuros-DM320Hardware <at> googlegroups.com
To unsubscribe from this group, send email to Neuros-DM320Hardware-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/Neuros-DM320Hardware
-~----------~----~----~----~------~----~------~--~---

headers

Dan Fandrich | 8 Mar 06:05

Re: PATCH dm9ks interrupt handling


On Wed, Mar 07, 2007 at 11:49:16PM -0500, mgao <at> neuros.us wrote:
> MG: One big part of the trouble (definitely not right yet, messy too?) is
> Ethernet DMA support. Currently the Ethernet packet receiving is directly
> handled by the ISR (which is why I am afraid taking out the packet limit check
> may cause holding the interrupt too long), thus DMA can not be fully supported
> without rewriting this part of the logic. The code today enables the DMA in the
> ISR but has to _wait_ till DMA is done, which is pretty pointless.
>  
> Does anyone have an idea of how this should be fixed?

Why not start the DMA in the ISR before exiting, then process the packet from
another ISR triggered by the end of the DMA transfer?

>>> Dan
--

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

headers

Michael Gao | 12 Mar 20:04

Re: PATCH dm9ks interrupt handling


On Wed, 2007-03-07 at 21:05 -0800, Dan Fandrich wrote:
> On Wed, Mar 07, 2007 at 11:49:16PM -0500, mgao <at> neuros.us wrote:
> > MG: One big part of the trouble (definitely not right yet, messy too?) is
> > Ethernet DMA support. Currently the Ethernet packet receiving is directly
> > handled by the ISR (which is why I am afraid taking out the packet limit check
> > may cause holding the interrupt too long), thus DMA can not be fully supported
> > without rewriting this part of the logic. The code today enables the DMA in the
> > ISR but has to _wait_ till DMA is done, which is pretty pointless.
> >  
> > Does anyone have an idea of how this should be fixed?
> 
> Why not start the DMA in the ISR before exiting, then process the packet from
> another ISR triggered by the end of the DMA transfer?
Yes, this is basically the idea. The challenge is how to split current
packet receive routine from simple synchronous operation to asynchronous
one.