Problem is not visable on a linux 2.4.26 kernel with the e1000-5x driver and the latest click from cvs.
Adam On 5/3/06, Adam Greenhalgh <[EMAIL PROTECTED]> wrote: > Beyers, > > I hope you had a good vacation. > > Have you been watching the e1000 list recently (or over the past few > months) ? There have been numerous problems with the driver in > general, ok mainly in the 6.X and 7.X branches of the code but it > isn't entirely clear as to what the actual cause is, but the driver is > look like it might be one cause of the problems. We are just building > a 32bit os image with a 2.4 kernel to see if we see the same problems > here as we do on the 2.6 kernel with the same hardware. I'll report > back soon. > > You are right about the packet flow, this raises the question as to > which path the host packets should follow when the driver is in > polling mode ? Show they go through the click routines or through > these "native" routines ? > > I am in two minds as to whether to push on with the 5.x/6.x branch of > the driver or try and move to the 7.x branch and take advantage of the > fixes the intel guys are doing. > > Adam > > Adam > > On 5/3/06, Beyers Cronje <[EMAIL PROTECTED]> wrote: > > Hi Adam, > > > > I was wanting to reply to your previous post on the mailing list, but have > > only gotten back from holiday yesterday. In short I still havent gotten a > > stable polling implementation on 2.6 yet :( > > > > From the investigation I've done it appears that when Linux transmits > > packets it does not go through the interrupt routine as you suspected, but > > instead Linux calls 'netdev->hard_start_xmit' which maps to > > e1000_xmit_frame in e1000_main.c > > > > The problem with interrupts being re-enabled while polling is active only > > occurs after the driver receives a transmit hang. This occurs after the > > driver calls e1000_tx_timeout_task which in turn calls e1000_up where > > interrupts are enabled again. e1000_up should theoretically only re-enable > > interrupts iff polling is not currently enabled, which it does not at this > > stage. > > > > But this is not the main bug, as we need to figure out why the transmit hang > > occurs in the first place, and as this occurs before interrupts are > > re-enabled it points to another more serious bug. > > > > Regards > > > > Beyers Cronje > > > > > > > > > > > > On 4/27/06, Adam Greenhalgh <[EMAIL PROTECTED]> wrote: > > > > > hi > > > > I'm playing with the e1000 driver and am trying to get it to work in > > polling mode with the 2.6 kernel. I'm seeing driver timeouts when > > sending packets from the local host because local host packets seem to > > be by passing the click part of the driver and are being delivered by > > the interrupt portion of the driver which I think is causing a race > > condition. > > > > Hence my question is this, which path should local packets follow when > > they are going to leave from an external interface ? My suspision is > > that they should not follow the interupt path if possible. > > > > Adam > > > > _______________________________________________ > > click mailing list > > click@amsterdam.lcs.mit.edu > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > > > _______________________________________________ click mailing list click@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
