Re: 8390 drivers

Michael Schmitz
2011-07-23T03:41:05Z

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
>>