Our default keymaps map "<=" to KS_Delete (i.e. vt-style rubout)
anyway, so default behavior is not changed, but some people might
prefer to map "<=" and "del" differently. Let them distinguish
between the two. Fix the flying windows key mapping it should be 219,
not 221 (menu). Drop non-existent keycode 125.
my ThinkPad 600E.
XXX isa_dmainit isn't called early enough for the 'audio at wss' attachment
XXX to work, so I'm deferring the call to 'wssattach' until later on. This
XXX should be fixed soon.
576000bps and 1152000bps. In the current published version of the data
sheet the MIR support documentation is gone, and the MIR mode bit is
documented as reserved. Possibly the device has a design flaw affecting
the MIR data rates? Document here that this information came from an
earlier data sheet, but leave MIR support in for the moment.
If a series of outputs are delivered to the device before the kernel thread
has polled for input data, any input data will be lost. As a
counter measure, always force an input check between outputs.
and avoid using MD myetheraddr() function.
This makes the driver MI, and closes PR kern/13797.
The PCI HME is a PCIO chip, which is composed of two functions:
function 0: PCI-EBus2 bridge, and
function 1: HappyMeal Ethernet controller.
The Ethernet address is (expected to be) in the PCI FCode PROM connected
to the EBus bridge (function 0) of the device.
Since the HME is on function 1, some magic is used to access to the PROM.
We don't have MI EBus driver since no EBus device exists (besides the
FCode PROM) on add-on HME boards. The ``not configured'' message for
function 0 is what is expected.
The SPARC case is currently unchanged. It needs interaction with OpenBoot.
card contains only one clock, which is already used by the other
DAC. The FM DAC can handle a few fixed-frequency choices.
thanks to Matthew Green for testing
- Fix typo in printf message.
- Don't use PCI_PRODUCT_DELTA_8139 (0x1360) for args of cardbus_conf_read()
and cardbus_conf_write(); use CARDBUS_INTERRUPT_REG (0x3c) instead.
cannot change the recording or playback mode of the device, it can
only change other mode-like values (like AUMODE_PLAY_ALL). Be very
explicit about fixing up the user's mode value based on the mode of
the device. Before, giving AUMODE_PLAY_ALL could cause AUMODE_PLAY
to become set on the device, and once AUMODE_PLAY_ALL was set it
was impossible to clear.
the MIF Configuration Register PHY_Select, there is no use in pretending
we could talk to both at the MII interface layer.
If both PHY are reported to be present, prefer the external one.
Remember this selection and enforce it in hme_mii_{read,write}reg.
This fixes problems with one of the dual hmes in Netra T1s.
From OpenBSD.
various orders depending how the upper level driver is flushing it's queue's.
This prevents the deadlocks I was seeing before with >8k writes.
XXX: Still not completely there as > 64k copies trigger bugs and the page
table support still needs to be written to break those down.
FreeBSD, with cleanup/KNF by me.
Note: These chipsets are not well supported by the i810 driver in
NetBSD's in-tree xsrc (based on XFree86 4.2.1 at this time). However,
the driver works perfectly using bleeding-edge XFree86-current on my
Omnibook's i830MG with these agp changes.
accept ranges as well as single addresses. Still need to go through any key
areas and remove the malloc's and replace these with some sort of pooling
instead.
The driver puts the adapter in promisc mode to receive multicast addresses.
At last set the IFF_PROMISC flag so that the upper layer filters frames
that are not for us.
Sure, the real fix would be to get multicast filters working ...
least 1us. Documentation I've found for the simple (SPP) parallel port
mode says that data should be stable 500ns before STROBE, STROBE should
be pulsed for no less than 500ns, and that data should be stable another
500ns after STROBE has been de-asserted.
Makes lpt@ebus on my Sun Ultra5 work with my HP DeskJet 712C, at least in
polled mode. Thanks to Martin for astutely noting it was probably a bug
with STROBE being pulsed too quickly.
1. Reduce debugging level to sane levels
2. Fix bugs in alloc_data_map related to allocing whole bytes of bitmap at
a time.
At this point the driver is functional. It talks to a local drive here and
can label/newfs. Performance is...lacking at the moment as its chewing cpu
heavily (probably due to the number of memcpy's) and will be the next area
attacked.
support up to the max ohci descriptor segments. Then attempt to fill it in
via a load. Use the number of segments filled in as the basis for figuring
out how many descriptors to supply to the ohci DMA engine.
XXX: Still needs to account for requests which because of splits may overflow
the 6 dma descriptors available today. For now this fixes cases where a
single 512 byte write was getting split into 2 dma segments from 1 incoming
iov request
The definitions were not the same between the scsi_messages file and this
definition so simply removing it here and letting the other one be used
results in incorrect behavior (regardless of whether it made the code
compile....)
- Call usbd_transfer_complete at splusb.
- Fix a botched for loop in ohci_rem_ed.
- In ohci_close_pipe, wait 1ms after removing an ED to avoid possible race
condition.
isochronous reception routine for IEEE 1394 OHCI (fwohci). The
transmission part is under construction.
The minimum configuration options for this feature are:
# IEEE 1394 (i.LINK)
fwohci* at pci? dev ? function ?
pseudo-device fwiso 1
This situation is normal for asynchronous sources, and the byte stuffing
algorithm used generates unpleasant noise.
Also take care of scattered data buffer and do memcpy correctly.
This should fix PR kern/16385.
1. Clean up some debugging and trigger some on only extreme debugging needs
2. Comment alloc data mapping a bit better and fix some of the bugs here
(note..there still are some so for now the free method is never called while
I track these down)
3. Fix the copying logic in data_resp. It was calculating negative offsets
which blew up memcpy.
At this point I can probe, inquire and get through the findroot steps of a
boot:
sd0 at scsibus0 target 0 lun 0: <Maxtor, 1394 storage, 60> disk fixed
sd0: mode sense (4) returned nonsense; using fictitious geometry
sd0: 76293 MB, 76293 cyl, 64 head, 32 sec, 512 bytes/sect x 156250000 sectors
sd0: mode sense (4) returned nonsense; using fictitious geometry
sd0: no disk label
findroot: can't open dev sd0a (6)
NOTE: This will panic my machine right now with a simple disklabel -r sd0.
Also, since the free mappings routines are if (0)'d out at the moment do not
use this code for anything except experiments and then only on a machine
you don't mind panic'ing.
Fixing the mapping routines will be the next step and then finally chasing
down the proper mode sense these drives understand.
- Add support for byte system bus mode. Based on patch in kern/17193 by
Christian Groessler, with some improvements by me.
- Rename sc_flags in mb86960_softc to sc_stat, rename "type" to sc_flags
to specify controller quirks and remove enum mb86960_type.
- Pass controller type via new sc_flags in mb86960_softc rather than
via an mb86960_attach() arg.
- Handle unaligned mbufs properly in mb86960_write_mbufs(). (from ne2000.c)
- Fix a signed/unsigned comparision warning.
- Add definitions of status bits in the RX packed header.
- Change types of some members in mb86960_softc.
This change makes the driver work properly for the following card,
which used to function a bit weird:
eap0 at pci0 dev 10 function 0: Ensoniq CT5880 CT5880C (rev. 0x02)
eap0: interrupting at irq 9
eap0: TriTech TR28602 codec; no 3D stereo
kristerw