Re: 8390 drivers

[Michael Schmitz <schmitzmic@googlemail.com>]

Hi Finn,
>> Is lib8390.c ever compiled standalone (as opposed to it being included
>> in each driver)?
>>     
>
> That probably depends on Christian's .config (I don't know how modularity 
> affects things) but in general yes: apne.c links in 8390.o. (Whereas hydra 
> and zorro8390 #include the library.)
>   
OK, I missed apne.c here - not sure it is even built in the default 
config though.
>> Either way, to avoid multiple inclusion of lib8390 symbols confusing the 
>> zorro8390 driver, Christian could disable the apne and eventual other 
>> ISA 8390 drivers in the build.
>>     
>
> If he did that instead of testing the patch, and fixed the problem, he 
> would then have to perform another test for the same patch, no?
>   
Right - I'm working on the assumption it is not necessarily symbol 
clashes. Duplicate symbols should have been reported at link time (or 
when a module is inserted, at latest).
>> If that's not helping, something in the Amiga interrupt code may be at 
>> fault. Your Mac driver withstands a flood ping OK (that still leaves you 
>> open to concurrent net and disk I/O presenting a problem BTW - 
>> transferring a big amount of data using netcat might be a better 
>> approximation of Christian's problem).
>>     
>
> Yes, but if the NIC works with idle disk and fails with SCSI load, would 
> you not blame the VIA driver?
>   
Not necessarily - there may be a driver locking out interrupts for too 
long so the timeout happens before the interrupt gets serviced. Not very 
likely - the timeout would have to run before the net bottom half.
> Anyway, I shall try that test before I send the patch for the VIA driver 
> to fix the nubus slot IRQ issue.
>
>   
>> The Atari EtherNEC driver has withstood 15 minutes of single-source 
>> flooding with a single log message:
>>
>> Jul 20 02:26:24 hobbes kernel: eth0: bogus packet: status=0x37
>> nxpg=0x4f size=102
>>
>> I've seen that quite a bit when transferring files in the past, but it
>> never stopped the driver from working.
>>
>> The main difference between the EtherNEC driver and the other 8390 
>> drivers is that I still link to 8390.o explicitly, instead of including 
>> lib8390.c (shame on me).
>>     
>
> I guess there are benefits to each approach? I assume that linking to 
> 8390.o, though simpler, would end up slower (?)
>   
That, and it ends up not using net_ops in the driver at all. Obsolete 
interface ...

  Michael

> Finn
>
>   
>> Cheers,
>>
>>   Michael
>>