docs don't seem to shed light on why this is needed, but reports from
the field indicate this helps prevent problems in this area. Ken's
changes seem to have exposed this bug, rather than caused it, as far
as I can tell.
Thanks to Jack O'Neill for tracking this down.
Submitted by: jack@germanium.xtalwind.net
Very strong 3.2 merge candidate.
Sync up device Ids with the master Adaptec list.
Add probe support for the 2940 Pro although it isn't obvious that
all of the termination support is correct for this adapter yet.
tell the sequencer to pause itself for a target msg variable update. This
avoids the pause race entirely as HS_MAILBOX can be accessed without
pausing the chip.
3.2 Merge candidate.
v1.19 (1999/04/15) updates the CEM56/REM56 support.
Current bugs & misfeatures
--------------------------
* CE2 cards still not working reliably. Unclear if this is related to
packet I/O code or interrupt handling.
* Autonegotiation support remains flaky. We're now OK with 10Mbit auto
hubs, but certain combination of hardware will fail to connect.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
v1.19 (1999/04/15) updates the CEM56/REM56 support.
Current bugs & misfeatures
--------------------------
* CE2 cards still not working reliably. Unclear if this is related to
packet I/O code or interrupt handling.
* Autonegotiation support remains flaky. We're now OK with 10Mbit auto
hubs, but certain combination of hardware will fail to connect.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
v1.18 (1999/04/08) adds support for CEM56 and REM56 multifunction cards.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
v1.18 (1999/04/08) adds support for CEM56 and REM56 multifunction cards.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
v1.17 (1999/03/28) has xperimental fixes to 10Mbit autonegotiation and
CE2 input lockup.
KNOWN BUGS
==========
* Media auto-negotiation is definitely not right. It will work in most
circumstances and seems to connect OK to most 100Mbit networks, however some
pathological combinations of hubs/networks/peers seem to confuse it.
* CE2 support is somewhat flakey (ranging from 'works perfectly' to 'hangs the
machine' so far). I've fixed the probe routine and a potential lockup in
the output routine, but a lot of people still report that they can't receive
or transmit.
* You won't be able to use the modem and Ethenet parts of a multifunction card
simultaneously. This is limitation the current FreeBSD PCMCIA support.
Likewise, there is no support for CardBus devices.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
v1.17 (1999/03/28) has xperimental fixes to 10Mbit autonegotiation and
CE2 input lockup.
KNOWN BUGS
==========
* Media auto-negotiation is definitely not right. It will work in most
circumstances and seems to connect OK to most 100Mbit networks, however some
pathological combinations of hubs/networks/peers seem to confuse it.
* CE2 support is somewhat flakey (ranging from 'works perfectly' to 'hangs the
machine' so far). I've fixed the probe routine and a potential lockup in
the output routine, but a lot of people still report that they can't receive
or transmit.
* You won't be able to use the modem and Ethenet parts of a multifunction card
simultaneously. This is limitation the current FreeBSD PCMCIA support.
Likewise, there is no support for CardBus devices.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
v1.16 (1999/03/08) fixed BPF input hang and infinite loop on CE2
short-packet output.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
v1.16 (1999/03/08) fixed BPF input hang and infinite loop on CE2
short-packet output.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
This driver is mostly based on the `xirc2ps' driver for Linux by Werner
Koch. Werner has even allowed his code to be distributed under a BSD licence,
making our life considerably easier -- thanks Werner!
This driver supports:
* Intel EtherExpress(TM) PRO/100 PCCARD (16-bit version)
* Xircom CreditCard CE2 / CEM28 / CEM33 / CE3 / CEM56 Ethernet adapters.
* Toshiba Advanced Network 10/100 PCCARD
* Certain Compaq Netelligent 10/100 branded cards
v1.14 has major changes to media selection code, and bugfixes in the
probe routine.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
This driver is mostly based on the `xirc2ps' driver for Linux by Werner
Koch. Werner has even allowed his code to be distributed under a BSD licence,
making our life considerably easier -- thanks Werner!
This driver supports:
* Intel EtherExpress(TM) PRO/100 PCCARD (16-bit version)
* Xircom CreditCard CE2 / CEM28 / CEM33 / CE3 / CEM56 Ethernet adapters.
* Toshiba Advanced Network 10/100 PCCARD
* Certain Compaq Netelligent 10/100 branded cards
v1.14 has major changes to media selection code, and bugfixes in the
probe routine.
Developed by: Scott Mitchell <scott@uk.freebsd.org>
Obtained from: http://www.freebsd-uk.eu.org/~scott/xe_drv/
udev_t in the kernel but still called dev_t in userland.
Provide functions to manipulate both types:
major() umajor()
minor() uminor()
makedev() umakedev()
dev2udev() udev2dev()
For now they're functions, they will become in-line functions
after one of the next two steps in this process.
Return major/minor/makedev to macro-hood for userland.
Register a name in cdevsw[] for the "filedescriptor" driver.
In the kernel the udev_t appears in places where we have the
major/minor number combination, (ie: a potential device: we
may not have the driver nor the device), like in inodes, vattr,
cdevsw registration and so on, whereas the dev_t appears where
we carry around a reference to a actual device.
In the future the cdevsw and the aliased-from vnode will be hung
directly from the dev_t, along with up to two softc pointers for
the device driver and a few houskeeping bits. This will essentially
replace the current "alias" check code (same buck, bigger bang).
A little stunt has been provided to try to catch places where the
wrong type is being used (dev_t vs udev_t), if you see something
not working, #undef DEVT_FASCIST in kern/kern_conf.c and see if
it makes a difference. If it does, please try to track it down
(many hands make light work) or at least try to reproduce it
as simply as possible, and describe how to do that.
Without DEVT_FASCIST I belive this patch is a no-op.
Stylistic/posixoid comments about the userland view of the <sys/*.h>
files welcome now, from userland they now contain the end result.
Next planned step: make all dev_t's refer to the same devsw[] which
means convert BLK's to CHR's at the perimeter of the vnodes and
other places where they enter the game (bootdev, mknod, sysctl).
bad math: it does not handle page-boundary conditions, and will not
end up mapping all of the requested addresses. This will cause a panic:
page fault during probe on some systems. I have a machine that will
panic every time (when using the dpt driver) on kernel probe when there
are 5 drives installed. When there are 4 drives, it is fine.
Fix is to always allocate/deallocate an extra page.
There is also a bonus splx() fix on an early error return.
Submitted by: Mark J. Taylor <mtaylor@cybernet.com>
PR: 9367
some aha 1542B cards will return 0x7f for the unimplemented GEOMETRY
register.
This is a good 3.2 candidate.
PR: 11469
Submitted by: Thomas David Rivers
displace a real driver.
Revert rev 1.109.
Pick up a few things from elsewhere (a couple of SiS id's).
As an *experiment*, have the chip* driver claim (for reporting purposes)
IDE controllers if there isn't another PCI-aware ide or ata driver to
grab them. I've exported the match function since it could be used from
the ata-all.c code replacing ata_pcimatch() - but I have not touched the
ata code. I'd like to catch a few more devices this way, including USB
and other bridges etc.
massive thwunking to include an XS_CHANNEL value. Some changes of how
parameters are reported to outer layers (including bus, e.g.). Yet more
stirring around in isp_mboxcmd to try and get it right. Decode of 1080/1240
NVRAM.
with other reset handling in rev.1.83 but broke it in rev.1.120. The
breakage didn't seem to cause any problems even on the system which had
problems ("extra" interrupts and botched handling thereof) before rev.1.83.
It only affects multi-floppy systems anyway.
after some of the previous commits). Add in support for the 1240
dual channel ISP card. Try the dance of unmapping a PCI interrupt
if we don't configure (if that ever works it'll be helpful).
