for the AN985 "Centaur" chip, which is apparently the next genetation
of the "Comet." The AN985 is also a tulip clone and is similar to the
AL981 except that it uses a 99C66 EEPROM and a serial MII interface
(instead of direct access to the PHY registers).
Also updated various documentation to mention the AN985 and created
a loadable module.
I don't think there are any cards that use this chip on the market yet:
the datasheet I got from ADMtek has boxes with big X's in them where the
diagrams should be, and the sample boards I got have chips without any
artwork on them.
It been awhile since the last major update, as a benefit there
are some cool things in this one (and new bugs probably :) )...
The ATA driver has grown "real" timeout support for all devices.
This means that it should be possible to get in contact with
(especially) lost ATAPI devices. It also means that the ATA
driver is now usable on notebooks as it will DTRT on resume.
An experimental hack at utilizing the Promise66's at UDMA66 is
in there, but I cant test it. If someone feels like sending
me one, give me a ping.
The ATAPI DMA enableling scheme has been changed, also better DMA
support for the Aladdin chipset has been implemented for ATAPI
devices. Note that the Aladdin apparently only can do DMA reads
on ATAPI devices, and the Promise cant do ATAPI DMA at all.
I have seen problems on some ATAPI devices that should be able
to run in DMA mode, so if you encounter problems with hanging
atapi devices during the probe, or during access, disable DMA
in atapi-all.c, and let me know. It might be nessesary to do this
via a "white list" for known good devices...
The ATAPI CDROM driver can now use eject/close without hanging and
the bug that caused reading beyond the end of a CD has been fixed.
Media change is also handled proberly. DVD drives are identified
and are usable as CDROM devices at least, I dont have the HW to
test this further, see above :).
The ATAPI tape driver has gotten some support for using the DSC
method for not blocking the IDE channel during read/write when
the device has full buffers. It knows about the OnStream DI-30
device, support is not completed yet, but it can function as a
primitive backup medium, without filemarks, and without bad media
handeling. This is because the OnStream device doesn't handle this
(like everybody else) in HW. It also now supports getting/setting
the record position on devices that supports it.
Some rather major cleanups and rearrangements as well (cvs -b diff
is your freind). I'm closing in on declaring this for beta code,
most of the infrastruture is in place by now.
As usual USE AT YOUR OWN RISK!!, this is still alpha level code.
This driver can hose your disk real bad if anything goes wrong, but
now you have been warned :)
But please tell me how it works for you!
Enjoy!
-Søren
Revert the major number back to 2.
libcrypt only export one function, before the recent changes and now:
char *crypt(const char *key, const char *salt);
The prototype didn't changed. Internal representation of `char' and `char *'
didn't changed. Therefore, there is no reason to change the version number.
`dst_port') work for outgoing packets.
- Make permanent links whose `alias_addr' matches the primary aliasing
address `aliasAddress' work for incoming packets.
- Typo fixes.
Reviewed by: brian, eivind
clustering issues (replacing code that used to be in
ufs/ufs/ufs_readwrite.c). vm_fault also now uses the new VM page counter
inlines.
This completes the changeover from vnode->v_lastr to vm_entry_t->v_lastr
for VM, and fp->f_nextread and fp->f_seqcount (which have been in the
tree for a while). Determination of the I/O strategy (sequential, random,
and so forth) is now handled on a descriptor-by-descriptor basis for
base I/O calls, and on a memory-region-by-memory-region and
process-by-process basis for VM faults.
Reviewed by: David Greenman <dg@root.com>, Alan Cox <alc@cs.rice.edu>
heuristic to detect sequential operation.
VM-related forced clustering code removed from ufs in preparation for a
commit to vm/vm_fault.c that does it more generally.
Reviewed by: David Greenman <dg@root.com>, Alan Cox <alc@cs.rice.edu>
transfer size calculation was incorrect resulting in the last read being
potentially larger then the actual extent of the device.
EOF and write handling has not yet been fixed.
Reviewed by: Tor.Egge@fast.no
the terminating zero by copying MAXCOMLEN + 1 bytes. This fixes the garbage
that occasionally appeared behind the programname when it is at least MAXCOMLEN
bytes long (such as communicator-4.61-bin).
submitter, who *still* hasn't bothered to answer me back.
The thing which the submitter completely failed to mention is that
his 3c900B-TPO card has the transceiver selection in the EEPROM set
to "auto." You can tweak the setting using the 3C90XCFG.EXE utility
that 3Com provides with the card. I'm not sure if it's supposed to
default to auto or if the user fiddled with it. Currently, the xl
driver only does autoselection for 10/100 NICs (i.e. those with NWAY
autonegotiation capabilities). For the 10baseT, 10base5, 10base2,
10baseFL and 100baseFX cards, the driver sets the default media to
whatever the EEPROM transceiver selector says. The problem is that
the "auto" selection is mistakenly identified as "10/100 NWAY
autoselection mode" and this is not handled correctly: the default
media ends up being chosen as 100baseTX, which doesn't work because
we've only added 10baseT media types to the ifmedia word. This leads
to a panic in ifmedia_set() (something else which the submitter never
bothered to mention).
A workaround for this is to re-run the 3C90XCFG.EXE utility and change
the transceiver selection to something besides "auto." I have also
patched the driver to watch for the "auto" setting in the non-miibus
case and select a reasonable default based on the card type instead of
falling through to 100baseTX and exploding.
PR: misc/13665
Rename dev->si_bsize_max to si_iosize_max and set it in spec_open
if the device didn't.
Set vp->v_maxio from dev->si_bsize_max in spec_open rather than
in ufs_bmap.c
spaces which cross a segment boundry in the page table. pmap_kextract()
is not designed for access to the user space portion of the page
table and cannot handle the null-page-directory-entry case.
The fix is to have vm_fault_quick() return a success or failure which
is then used to avoid calling pmap_kextract().
This whole idea isn't going to work until somebody makes the bus/kld
code smarter. The idea here is to change the module's internal name
from "foo" to "if_foo" so that ifconfig can tell a network driver from
a non-network one. However doing this doesn't work correctly no matter
how you slice it. For everything to work, you have to change the name
in both the driver_t struct and the DRIVER_MODULE() declaration. The
problems are:
- If you change the name in both places, then the kernel thinks that
the device's name is now "if_foo", so you get things like:
if_foo0: <FOO ethernet> irq foo at device foo on pcifoo
if_foo0: Ethernet address: foo:foo:foo:foo:foo:foo
This is bogus. Now the device name doesn't agree with the logical
interface name. There's no reason for this, and it violates the
principle of least astonishment.
- If you leave the name in the driver_t struct as "foo" and only
change the names in the DRIVER_MODULE() declaration to "if_foo" then
attaching drivers to child devices doesn't work because the names don't
agree. This breaks miibus: drivers that need to have miibuses and PHY
drivers attached never get them.
In other words: damned if you do, damned if you don't.
This needs to be thought through some more. Since the drivers that
use miibus are broken, I have to change these all back in order to
make them work again. Yes this will stop ifconfig from being able
to demand load driver modules. On the whole, I'd rather have that
than having the drivers not work at all.
usually cleared by a successful selection, but there is no guarantee
that a future successful selection will ever occur (e.g. empty bus).
The driver never looks at SELINGO, but the busy LED does, so this
change has the cosmetic effect of fixing the rare instance where the
busy LED was left on, confusing the user.
