DragonFly bugs List (threaded) for 2008-05
DragonFly BSD
DragonFly bugs List (threaded) for 2008-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: an0: device timeout on x31


From: "Sepherosa Ziehau" <sepherosa@xxxxxxxxx>
Date: Sun, 18 May 2008 19:02:55 +0800

On Sun, May 18, 2008 at 6:32 PM, Sepherosa Ziehau <sepherosa@gmail.com> wrote:
> On Sun, May 18, 2008 at 6:26 PM, Sepherosa Ziehau <sepherosa@gmail.com> wrote:
>> On Sun, May 18, 2008 at 6:22 PM, Sepherosa Ziehau <sepherosa@gmail.com> wrote:
>>> On Sun, May 18, 2008 at 6:01 PM, Jost Tobias Springenberg
>>> <jspringe@uos.de> wrote:
>>>>
>>>>> Do you mean even low rate traffic like ping?
>>>>>
>>>> Nope that works fine only if I try to transfer i.e. a tarball.
>>>>
>>>>> Things like:
>>>>> - write to IO registers when device is not initialized yet or when
>>>>> device is powered off
>>>>> - write to IO registers that do not exist
>>>>> - Initialize RX/TX ring related IO registers, before RX/TX ring is initialized.
>>>>> - RX/TX ring is not correctly initialized
>>>>> - buffer is (wrongly) freed/trashed when device is doing DMA
>>>>
>>>> What really strikes me is the following:
>>>> I tried 12.1 release and HEAD without any changes, just as they are in the repos.
>>>>
>>>> On 12.1 livecd I get the errors that I wrote about in my first post,
>>>> but no freezes at all, even if transferring files (although performance is horrible due to the massive timeouts).
>>>>
>>>> While using HEAD the system shows the same behavior but freezes after a few pings ...
>>>>
>>>> That suggests that the problem is not due to the changes I made but a more general bug !?
>>>> What has changed in the network related areas since 12.1 ?
>>>> May it be related to Sephes changes ?
>>>
>>> Maybe, can you break into DDB when freezing happens?
>>
>> Its a bug in the driver about how IFF_OACTIVE should be handled.  I
>> will work out a fix.
>
> Can you test following patch on HEAD:
> http://leaf.dragonflybsd.org/~sephe/if_an_oactive.diff
>

BTW, is your card MPI350?  Its TX desc setup looks suspecious:
~line 2615 if_an.c
                        for (i = 0; i < sizeof(an_tx_desc) / 4 ; i++) {
                                CSR_MEM_AUX_WRITE_4(sc, AN_TX_DESC_OFFSET
                                    /* zero for now */
                                    + (0 * sizeof(an_tx_desc))
                                    + (i * 4),
                                    ((u_int32_t*)&an_tx_desc)[i]);
                        }

Physical address of the buffer is at the high end of the TX desc, but
valid bit is at the low end of the TX desc, which means we tell
hardware the TX desc is valid before we tell it the buffer's physical
address.  This probably explains the watchdog timeout.

I think if your card is MPI350, you probably want to change the above code into:
                        for (i = sizeof(an_tx_desc) / 4 - 1; i >= 0; --i) {
                                CSR_MEM_AUX_WRITE_4(sc, AN_TX_DESC_OFFSET
                                    /* zero for now */
                                    + (0 * sizeof(an_tx_desc))
                                    + (i * 4),
                                    ((u_int32_t*)&an_tx_desc)[i]);
                        }

Best Regards,
sephe

-- 
Live Free or Die



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]