whatever reason), return 0 instead of the default
RF_RECON_READ_STOPPED. Returning RF_RECON_READ_STOPPED would result
in rf_ContinueReconstructFailedDisk() thinking that the given
component was "done" and breaking out of the main reconstruction loop
far too early. Reconstruction still worked correctly as long as there
were no errors, but RAIDframe wouldn't be in a position to properly
handle read/write errors during reconstruction.
This fixes the "raidctl's progress bar spins at 0% until
reconstruction finishes" problem.
Change a boundary check to ensure that we won't accidentally read and use
uninitialized memory if ATA_RAID_TYPE_MAX is updated without updating the
array.
Update comment near ATA_RAID_TYPE_MAX to note that the array in ata_raid.c
should be updated if a new ATA_RAID_TYPE_* is added.
"International English" (#ABB) unit from Christer Andersson.
US version (#ABA) uses the same primary layer layout as far as I can
figure from keyboard pictures, so this table should work for those
machines too.
the NIC decryptes & decapsulates WEP frames before passing them to
the host. "Remember" the state of IEEE80211_F_DROPUNENC in
sc_ic_flags, though, and try our best to honor it as we setup the
hardware state.
This is the second patch of this kind. The previous patch was
badly broken because wi_mend_flags was basing its decision to clear
IEEE80211_F_DROPUNENC based on the operating state we were
transitioning FROM instead of the state we were transitioning TO.
This fixes a bug that Simon Burge reported, where dhclient wi0
would not get a lease unless and until you ran 'ifconfig wi0'
concurrently (which would frob the IEEE80211_F_DROPUNENC bit in
the right way). This patch was tested by Simon with his Toshiba
Lucent-clone.
to config_found()
(after some cleanup we might be able to kill SCSIPI_BUSTYPE_*)
-remove scsipiprint() -- the parts which make it differ from
scsiprint()/atapiprint() were unreachable anyway
back out my change to ieee80211_crypto_encap that made it free its
mbuf argument on error. I had thought it was a bug. It was not.
It's the drivers that are broken. Make an(4), atw(4), ipw(4),
iwi(4), ral(4), rtw(4), ural(4), and wi(4) free the mbuf when
ieee80211_crypto_encap returns NULL. Also, return ath(4) to the
way it was---i.e., free the mbuf.
Thanks to Sam Leffler to pointing out my mistake.
augustss