support this feature. This avoids multiple crashes that I've had in the
past. Also ensure that packets are not empty when DIAGNOSTIC is set.
However, this is just another sanity check of the received packets, but
does not address the real problem. The issue seems to be the following:
if the card receives data while doing a reset (vr_init), it later finds
a bunch of empty packets in the receive ring.
This explains the crashes I've hit: running a program which needs
promiscuous mode (dhclient) while the card was already running in
that mode (tcpdump). In this situation, it's easy that the second
reset receives stuff from the network.
Unfortunately, I don't know why the card is producing these packets...
While here, fix a typo in a comment.
Make the transmit section reserve one descriptor for issuing a
command at all times. If either transmit descriptors run out, or
header/buffer software descriptors run out, set IFF_OACTIVE and
get out of ipw_start, rather than re-using a descriptor or trying
to use a NULL descriptor that comes off the front of an empty
descriptor tailqueue.
This ought to fix port-i386/27439 and kern/28683.
- fix a panic in mach64_alloc_screen()
- some cleanup
- restrict mach64_mmap() to addresses which belong to it
- mach64_attach now prints bus addresses instead of kernel vm addresses
- initial support for macppc
(violating the PC Card spec), so... use the "power cycle" socket event to
determine when we've reached Vcc before proceeding, rather than using a fixed
amount of time. This has the double advantage that it makes the card attach
time even shorter on sane systems -- the minimum is now ~38ms on my i8500
rather than 222ms.
Probably a similar change should be made to pcic, but it was hard enough
figuring out whether it would work with pccbb. The chip specs suck.
For now, I'm leaving in a couple of additional printf()s in the hope that I
will get some interesting data from them.
christos