Re: Call for stge(4) testers

On Thu, Jul 13, 2006 at 05:20:09PM +0000, Bill Paul wrote:

[...]

 > 
 > > However in the long run it did work
 > > after about a minuate without any action from user.
 > 
 > Hm. Well, here's the thing: ethernet controller's can't tell time. I
 > think it's less of an issue of how much time it takes before the NIC
 > starts sending jumbo frames correctly and more of an issue of how
 > many failed transmission attempts occur before one succeeds. Did you
 > count the number of bad transmissions that occur before the chip
 > starts working? Was it always the same number? Did you instrument
 > the interrupt handler to see if TX completion events are actually
 > occuring for each transmission? (Just because you made it into

No I didn't. Because it now works as expected I didn't want to try
again. Well, experimenting with jumbo frame is time consuming task
and I'm running out all my spare time.

 > stge_start() and queued the packet up doesn't mean transmission
 > completed?)
 > 
 > 

[...]

 > > That's exactly what I did it on my tests. From your detailed
 > > explanation on jumbo frame internals and guide I've reread source
 > > code related to jumbo frame and managed to find a bug in my code.
 > > It was my programming error in selecting an MTU from ioctl handler.
 > > However I don't understand how the hardware can send/receive larger
 > > MTUs than 9022.
 > 
 > What is it about this that you don't you understand, exactly? Is it
 > something about this particular chip, or about being able to have
 > frames larger than 9022 bytes in general? (Technically jumbo frames
 > can be up to 16K in length, but by convention most people use 9000
 > bytes.) Mind you, this is one chip I've never gotten around to writing
 > a driver for myself, so I'm sure I'm missing something.
 > 

I meant I wondered how it could send/receive a larger sized frame than
9022 bytes which is the max. supported size on TC9021.

 > > If you program the hardware to receive 10K it
 > > eventually work in a one or two minute.
 > 
 > Like I said, it's probably a question of some sequence of events
 > occuring before it starts to work, not the passage of a certain amount
 > of time. It may be that you have to disable and re-enable the TX and/or
 > RX dma engines before switching to the larger frame size. Also, verify
 > that you properly initialize all of the fields in the TX descriptors
 > on each transmission so you're not keeping stale bits set from
 > previous transmissions. There's also a slight chance this is a stack
 > bug, not a driver/chip bug. What happens if you do:
 > 
 > # ifconfig stge0 mtu 9000
 > # ifconfig stge0 down
 > # ifconfig stge0 up
 > 
 > Does it still take a minute for transmissions to succeed?
 > 

No, it now works as expected in all situations. Of course, there is
no need to bring the interface down/up after changing an MTU.

Thanks a lot.
-- 
Regards,
Pyun YongHyeon