CIS MAC only on error.
(NetBSD these days tries to read the MAC address from the PCMCIA
CIS. Prism cards made by Senao set the MAC in every PCMCIA CIS to
00:02:6f:00:02:15. In a network of Senao cards, this causes MAC
duplication.)
determine if we are willing to wait for memory to come from the
diskqueuedata (dqd) and bufpool pools. Cleanup the mess related to
code calling rf_CreateDiskQueueData() with different expectations
(and/or blatent disregard) of what might happen if there were
insufficient pool resources.
that occurs during a reconstruction. We go from zero error handling
and likely panicing if something goes amiss, to gracefully bailing and
leaving the system in the best, usable state possible.
- introduce rf_DrainReconEventQueue() to allow easy cleaning of the
reconstruction event queue
- change how we cleanup the floating recon buffers in
rf_FreeReconControl(). Detect the end of the list rather
than traversing according to a count.
- keep track of the number of pending reconstruction writes. In the
event of a read error, use this to wait long enough for the pending
writes to (hopefully) drain.
- more cleanup is still needed on this code, but I didn't want to
start mixing major functional changes with minor cleanups.
XXX: There is a known issue with pool items left outstanding due to
the IO failure, and this can show up in the form of a panic at the
tail end of a shutdown. This problem is much less severe than before
these changes, and the hope/plan is that this problem will go away
once this code gets overhauled again.
devices found in many embedded systems. They must be polled and
debounced in software. Should be able to handle any size matrix keypad, but
only tested with a 4x4 (16-key) device attached to the TS-7200 ARM embedded
board via the DIO header.
for TOC response format 1 and 2 are mandatory on CD/DVD too and provide
more information.
Next an IOCTL needs to be implemented that can read all TOC formats in a
generic way. This is pending.
frontend for the split re(4) to files.cardbus, and to the generic x86
laptop config (sys/i386/conf/GENERIC_LAPTOP).
NB: as best I know, there are still unresolved issues in attach and
powersave, with the NetGear cardbus cards and re(4).
call audio_clear() only when blocksizes are actually changed.
This fixes a problem on some audio devices and applications which
use ossaudio and call SNDCTL_DSP_GETOSPACE repeatedly while playing.
* audiostartp()
add some debug prints.
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.
create and queue a new one that carries the new BSSID. I mined
net80211 in FreeBSD for the solution, which is to make an
IEEE80211_S_RUN->IEEE80211_S_RUN state transition---ath_newstate
discards the old beacon packet creates a new one by calling
ath_beacon_alloc.
I tested the merge as follows. Starting at my desk on the second
floor of the building where I work:
soekris% ifconfig ath0 mediaopt adhoc ssid zzz chan 11 down
powerbook% ifconfig rtw0 mediaopt adhoc ssid zzz chan 11 up
soekris% sleep 25; ifconfig ath0 up
I raced to the elevator with my Powerbook, pressed the "Down"
button, got in, and pressed "Floor 1." At the first floor:
powerbook% ifconfig rtw0 | grep bssid
bssid 02:p:p:p:p:p chan 11
I waited 25 seconds. I pressed "Floor 2." At Floor 2, I returned to my desk.
I checked to make sure that the Soekris console read:
soekris% ath0: creating bss 02:s:s:s:s:s
ath0: bss merge 02:s:s:s:s:s -> 02:p:p:p:p:p
0:s:s:s:s:s is the Soekris' WLAN MAC. 0:p:p:p:p:p is the Powerbook's
WLAN MAC. Each created an ad hoc-mode BSSID from its WLAN MAC by
OR'ing 0x2 with the first octet.
My Powerbook created a network while the Soekris radio was off.
The Soekris radio turned on while I was in the 802.11-impervious
elevator with my Powerbook. When I returned to the second floor,
the Soekris "heard" beacons from my Powerbook as the elevator door
opened. Since the Powerbook's network was approximately 25 seconds
older than the Soekris', and since it had the same SSID (zzz) as
the Soekris', the Soekris merged with the Powerbook's network (by
setting its BSSID) as it should.
on "options PMS_SYNAPTICS_TOUCHPAD" in the kernel config file. See
the PR for details on why this is necessary.
While here, defflag PMS_DISABLE_POWERHOOK.
pfckbd_callout_hp() does. Change the order of scan and the layout of
the matrix to be more natural.
Chords like <Shift>+<L> now work.
From KIYOHARA Takashi.
- 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
rtw_set_access, rtw_set_access1 to match.
Add a subroutine for setting WEP keys. WEP isn't quite finished,
because I have to add the WEP header to Tx packets. Implement the
SIOCS80211NWKEY ioctl for setting WEP keys.
Program the LEDs based on operating state and packet activity.
* On a Revision F RTL8180, blink LED1 at 1Hz to indicate
scan/authenticate/associate states. In the run state, turn LED1
on. In every state, blink LED1 at 5Hz to indicate non-beacon
tx/rx activity. I would like to use two LEDs, but in all my
Rev. F instances, LED0 is not wired to an LED; instead, the
first LED is wired to indicate that the card's power is on.
* On a Revision D RTL8180, program the LEDs so that LED0 indicates
Tx, and LED1 indicates Rx. The Rx LED will blink annoyingly if
there are beacons in the air, but at least the Tx LED is useful.
* Store the hardware revision in the softc to support my futile
attempt at programming LEDs for both Rev. D and Rev. F parts;
I never did get Rev. D LEDs to work right.
* Add a debug flag RTW_DEBUG_LED for the LED transitions.
Add RTW_TPPOLL_ALL, RTW_TPPOLL_SALL to start and stop, respectively,
all of the transmit rings.
In ad hoc mode, allocate a beacon and load it into the beacon ring.
Start the ring. In one trial, the card re-transmitted the beacon
ring's contents several times before stopping. More programming
and testing for ad hoc mode is necessary. I'm not setting the
beacon flag in the transmit descriptor.
Revamp the transmit section to make better use of all the transmit
rings: beacon queue, high-, low-, and medium-priority rings. Put
beacon frames on the beacon ring. All other management frames,
and data frames, go on the medium-priority ring. Power-save data
frames go on the high-priority ring. (Note that powersaving is
not implemented!) This is a work in progress.
Send all 802.11 Management frames at 1Mbps.
After we put a packet on a transmit ring, tickle the right bit in
the TPPOLL to tell RTL8180. Stop all rings on error and in rtw_stop.
Use the RF chip type, not the RTL8180 revision, to choose between
host- and MAC-controlled RF serial I/O. Now the Netgear MA521
works.
Remove bogus definition of bit RTW_TPPOLL_FSWINT.
(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.
"oversize frame." Also, some an(4) instances (esp. w/ firmware
version 5+) would not reliably interoperate with some Cisco APs.
Add a sysctl for enabling/disabling debugging.
The problem with Aironet AP interoperability was that the rx frame
'gap' will sometimes be loaded with the 802.2 SNAP header, and
sometimes omitted, when connected to a Cisco AP; an(4) was *always*
discarding the gap. The problem with "oversize frames" was an
off-by-2 error in the frame-length arithmetic.
While we're here, pad some RIDs to the length that new firmware
really expects.
Thanks to Jim Miller for his valuable bug reports and testing, and
to Dheeraj Reddy for RID-length patches. Some clues from various
Linux drivers for Cisco/Aironet cards led to the gap fix.
