Re: [PATCH] starfire reads irq before pci_enable_device.

Ion Badulescu
2001-02-08T22:16:35Z

On Thu, 8 Feb 2001, Donald Becker wrote:

> > > The align-copy should *never* be required because the alignment differs
> > > between DIX and E-II encapsulated packets. The machine shouldn't crash
> > > because someone sends you a different encapsulation type!
>
> This is true for a number of drivers -- triggering the copy-align code
> might eliminate the misaligned traps on your local network, but it's not
> a solution.

Ok, so what *is* a good solution then? I'm not arguing that unaligned
memory access traps should be avoided because they are deadly (they
shouldn't be), but because they are costly.

Or we can just tell people, "hey, don't use this 64-bit PCI card on a real
64-bit system, it's broken by design"? I don't think that's a good
solution either.

The lack of a 64-bit frame descriptor isn't going to help either, if and
when zerocopy makes into the official tree. Using buffer descriptors with
fragmented sk_buffs is *not* fun (and yet that's what I do in 32-bit for
my BSDI driver, but for unrelated reasons).

> I saw the Adaptec people last week at LinuxWorld. The 2.4.0 starfire
> has a number of actual bugs that should be fixed RSN:
> The consistency check in the Rx code was broken. Did anyone ever try
> the driver after the changes? The test triggers with every received
> packet. The easiest patch is to just get rid the consistency checks
> inside "#ifndef final_version".

Done.

> The region resource was not released, requiring a reboot between each
> driver test. Trivial fix.

Done.

> The MII read code is no longer reliable. I spent twenty minutes at
> the show, but couldn't figure out the problem. I haven't been able
> reproduce the problem locally with my 2.2 code and someone older
> hardware.

Yes, I've noticed this too, the PHY doesn't seem to get detected in all
cases, and it's pretty random at that. Other times the same PHY gets
detected multiple times at different addresses.

The good news is that the same code behaves the same on 2.4 and 2.2, so
I think it's not a core kernel issue. I'll try to track it down;
fortunately it doesn't affect card functionality as long as the user
sticks with autonegotiation.

Thanks,
Ion

--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.