GEOM and using READ CD command for reading data, same as acd driver does.
Audio CDs identified by checking respective bit of the control field of
the first track in TOC.
This fixes bunch of error messages during boot (GEOM taste) with Audio CD
inserted and allows to grab Audio CD image using just dd.
MFC after: 1 month
import:
- Add read-only sysctls for all of the tunables supported by the igb and
em drivers.
- Make the per-instance 'enable_aim' sysctl truly per-instance by having it
change a per-instance variable (which is used to control AIM) rather
than having all of the per-instance sysctls operate on a single global
variable.
While here, restore the previously existing hw.igb.rx_processing_limit
tunable as it is very useful to be able to set a default tunable that
applies to all adapters in the system.
and sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:
sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:577:24: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion]
return HAL_EINVAL;
~~~~~~ ^~~~~~~~~~
and:
sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:164:9: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion]
return HAL_OK;
~~~~~~ ^~~~~~
In both cases, enums HAL_BOOL and HAL_STATUS are mixed up.
MFC after: 1 week
and sys/dev/ath/ath_hal/ar5211/ar5211_power.c:
sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3: warning: signed shift result (0x200000000) requires 35 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sys/dev/ath/ath_hal/ah_internal.h:472:42: note: expanded from:
(OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) & (_f)))
^
sys/dev/ath/ah_osdep.h:127:49: note: expanded from:
(bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val))
^~~~
The AR_SCR_SLE_{WAKE,SLP,NORM} values are pre-shifted in ar5210reg.h and
ar5211reg.h, while they should be unshifted, like in ar5212reg.h. Then,
when the OS_REG_RMW_FIELD() macro shifts them again, the values will
overflow, becoming effectively zero.
MFC after: 1 week
At work, where we use use KVM+QEMU, we notice that pxeboot is pratically
impossible because of network timeouts. This is due to the fact that the
RTC code makes aggressive jumps.
Two RTC reads does not seem to be sufficient. Change the code to check
for 8 identical RTC values.
Sponsored by: Kumina bv
as it gets the following warning:
sys/dev/asr/asr.c:1836:29: warning: array index of '58' indexes past the end of an array (that contains 1 element) [-Warray-bounds]
while ((len > 0) && (sg < &((PPRIVATE_SCSI_SCB_EXECUTE_MESSAGE)
^
sys/dev/asr/i2omsg.h:934:8: note: array 'Simple' declared here
I2O_SGE_SIMPLE_ELEMENT Simple[1];
^
This is a false positive, since I2O_SG_ELEMENT::Simple is not declared
as a C99 flexible array member, but in the old (but more portable) way.
At run-time, the proper number of array elements will hopefully have
been allocated.
MFC after: 1 week
there are some places in the kernel where fixing them is too disruptive,
or where there is a false positive.
In this case, disable -Wconstant-conversion for two aic7xxx-related
files, as they get the following warning on i386 (and possibly on other
32-bit arches):
sys/dev/aic7xxx/ahc_pci.c:112:10: warning: implicit conversion from 'long long' to 'bus_addr_t' (aka 'unsigned int') changes value from 549755813887 to 4294967295 [-Wconstant-conversion]
? 0x7FFFFFFFFFLL
~~^~~~~~~~~~~~~~
This is a false positive, since the code only passes the 0x7FFFFFFFFFLL
argument, if sizeof(bus_addr_t) is larger than 4 (e.g. on 64 bit arches,
or when PAE is enabled on i386). The code could be refactored to do
compile-time checks, but that is more disruptive.
MFC after: 1 week
In the future we may want to perform the switch even if the console is
currently in the graphics mode by trying to reset the video adapter first
(e.g. by executing vesa/vga bios post). That would probably require
some sort of a one-way flag as returning the control of the console back
to the interrupted application most likely would result in a mess.
Reviewed by: emaste
MFC after: 2 months
This change is designed to let USB keyboard work in the panic context
with stop_scheduler_on_panic=1. Most of change consists of removing
mtx_owned() checks where they can be easily avoided. Some additional
lock cleanup is performed along the way.
A list of the smaller changes:
- newbus methods should be executed with Giant already held, just assert
this
- kbd methods called in the non-polling context should be executed with
Giant already held, just assert this
- Giant is recursive, so we should just take it where we must have it,
without redundant checks if we already have it
- thanks to recent syscons changes we don't need to go through the hoops
to detect if kernel is going to poll us; polling mode is now clearly
separated from non-polling mode
- at present the polling mode can be entered by only one thread
- document special cases in greater detail
Please note that the ukbd code and underlying USB code still lve
dangerously in the kdb context by trying to obtain various locks
including the Giant. If any of those locks are already held by the
stopped threads, then the things would blow up.
Another limitation of the ukbd driver is that it is detached before a
system enters the halt state.
With this commit we can enable kern.stop_scheduler_on_panic by default,
that should not introduce any regressions.
Reviewed by: hselasky
MFC after: 3 months
X-MFC after: r228424, r228760
When SCHEDULER_STOPPED() is true the mtx_owned() call may return
an unexpected and thus meaningless result.
So, in the code paths that can be reached when SCHEDULER_STOPPED() is true
we need to protect the mtx_owned() calls with the SCHEDULER_STOPPED()
checks and ensure that an appropriate branch is taken in each case.
Reviewed by: hselasky
MFC after: 3 months
X-MFC after: r228424
get a reply of EEXIST from an NFS server when a Mkdir RPC was retried,
for an NFS over UDP mount.
Upon investigation, it was found that the client was retransmitting
the Mkdir RPC request over UDP, but with a different xid. As such,
the retransmitted message would miss the Duplicate Request Cache
in the server, causing it to reply EEXIST. The kernel client side
UDP rpc code has two timers. The first one causes a retransmit using
the same xid and socket and was set to a fixed value of 3seconds.
(The default can be overridden via CLSET_RETRY_TIMEOUT.)
The second one creates a new socket and xid and should be larger
than the first. However, both NFS clients were setting the second
timer to nm_timeo ("timeout=<value>" mount argument), which defaulted to
1second, so the first timer would never time out.
This patch fixes both NFS clients so that they set the first timer
using nm_timeo and makes the second timer larger than the first one.
Reported by: jwd
Tested by: jwd
Reviewed by: jhb
MFC after: 2 weeks
initializing structures, like the pv table, that are only used to
implement superpages. In fact, some of the unnecessary code in
pmap_init() was actually doing harm. It was preventing the kernel from
booting on virtual machines with more than 768 MB of memory.
Tested by: sbruno
- Fix boot0 to check for PXE when using the pre-set setting for the
preferred slice.
- Update boot0cfg to use slice 6 to select PXE. Accept a 'pxe' argument
instead of a number for the 's' option as a way to select PXE as well.
Submitted by: Andrew Boyer aboyer averesystems
MFC after: 2 weeks
7.x, 8.x and 9.x with pf(4) imports: pfsync(4) should suppress CARP
preemption, while it is running its bulk update.
However, reimplement the feature in more elegant manner, that is
partially inspired by newer OpenBSD:
- Rename term "suppression" to "demotion", to match with OpenBSD.
- Keep a global demotion factor, that can be raised by several
conditions, for now these are:
- interface goes down
- carp(4) has problems with ip_output() or ip6_output()
- pfsync performs bulk update
- Unlike in OpenBSD the demotion factor isn't a counter, but
is actual value added to advskew. The adjustment values for
particular error conditions are also configurable, and their
defaults are maximum advskew value, so a single failure bumps
demotion to maximum. This is for POLA compatibility, and should
satisfy most users.
- Demotion factor is a writable sysctl, so user can do
foot shooting, if he desires to.
* Right now the delay is hard coded at 10uS. This is a bit long when doing lots
of periodic i2c transactions. So create a 'udelay' parameter and initialise it
to 10. This can be tuned later.
* Add a newline after a transaction finishes, so the debugging output isn't so
horrible.
performance issues.
* Access to the GPIO bus is already locked by requesting
and releasing the bus - thus the lock isn't really needed
for each GPIO pin change.
* Don't lock and unlock the GPIO bus for -each- i2c access -
the i2c bus code is already doing this by calling the upper
layer callback to request/release the bus. This thus locks
the bus for the entirety of the transaction.
TODO:
* Further verify that everything is correctly requesting/
releasing the GPIO bus.
* Look at how to lock the GPIO pin configuration stuff,
potentially by locking/unlocking the bus at the gpiobus
layer.
With the previous code, if the range of priorities for timeshare batch
threads was greater than RQ_NQS, then the threads with low priorities in
the part of the range above RQ_NQS would be scheduled to the run-queues
as if they had high priorities at the beginning of the range.
In other words, threads with a nice level of +N could be scheduled as
if they had a nice level of -M.
Reported by: George Mitchell <george@m5p.com>
Reviewed by: jhb
Tested by: George Mitchell <george@m5p.com> (earlier version)
MFC after: 1 week
Fix the TCP header size calculation such that makes TSO engine
cache all header(ethernet/IP/TCP) bytes to its internal buffer.
While here, remove extra pull up for TCP payload. Unlike some
em(4) controllers, fxp(4) does not require such work around for
TSO.
The two limitations are ethernet/IP/TCP header size should be less
than or equal to the size of controller's internal buffer(80 bytes)
and these header information should be found in the first fragment
of a TSO frame.
of the rx_ring to bus_dmamap_sync(9). Given that netmap code tries to
obtain the bus addresses of netmap buffers via vtophys(9) instead of using
bus_dma(9) it currently has zero chance of actually working on sparc64
though (and for that matter f.e. also not with MACs limited to 32-bit DMA
on x86 machines with more than 4GB of RAM).
