and never remove state.
This fixes the problem some people are seeing that state is removed when pf
is loaded as a module but not in situations when compiled into the kernel.
Reported by: many on freebsd-pf
Tested by: flo
MFC after: 3 days
With the addition of various GEOM layers some device names now exceed
this length, for example /dev/mirror/encrypted.elig.journal. This
change expands the field to 53 bytes which brings the /etc/dumpdates
lines to 80 characters. Exceeding 80 characters makes the /etc/dumpdates
file much less human readable. A test is added to dump so that it
verifies that the device name will fit in the 53 character field
failing the dump if it is too long.
This change has been checked to verify that its /etc/dumpdates file
is compatible with older versions of dump.
Reported by: Martin Sugioarto <martin@sugioarto.com>
PR: kern/160678
MFC after: 3 weeks
If we handle an interrupt just before the 'wait' and the interrupt
schedules some work, we need to skip the 'wait' call. The simple solution
of calling sched_runnable() with interrupts disabled immediately before
wait still leaves a window after the call and before 'wait' in which
the same issue can occur.
The solution implemented is to check the EPC in the interrupt handler, and
if it is in a region before the 'wait' call, to fix up the EPC to skip the
wait call.
Reported/analysed by: adrian
Fix suggested by: kib
Reviewed by: jmallett, imp
As the underlying block is 4KB if the PMC throughput is low the measurement
will be reported on the next tick. pmcstat(8) use the modified flush API to
reclaim current buffer before displaying next top.
MFC after: 1 month
As part of the 8.0-RELEASE cycle this was done in stable/8 (r199112)
but was left alone in head so people could work on fixing an issue that
caused boot failure on some motherboards. Apparently nobody has worked
on it and we are getting reports of boot failure with the 9.0 test builds.
So this time I'll comment out the driver in head (still hoping someone
will work on it) and MFC to stable/9.
Submitted by: Alberto Villa <avilla at FreeBSD dot org>
the text of the menu selections doesn't get displayed properly and it
makes the installer appear to lock up for no obvious reason.
Reviewed by: nwhitehorn
- In the argc == 0 case, just populate the mount list as before, but
do not calculate widths, update totals or print anything.
- In the argv > 0 case, collect information about the requested file
systems and store it in the mount list, but do not calculate
widths, update totals or print anything.
- In either case, once all the information has been collected,
iterate once through the mount list to calculate widths and totals,
then once more to print everything.
This also fixes two bugs: firstly, column widths were not calculated
correctly if more than one file system was specified on the command
line; and secondly, file systems with MNT_IGNORE were included in the
totals even if -a was not specified.
Noticed by: Paul Schenkeveld
MFC after: 3 weeks
- update xlp_machdep.c to read arguments from FDT if FDT support is
compiled in.
- define rmi_uart_bus_space, and use it as fdtbus_bs_tag
- update conf files for FDT support
- add default dts file xlp-basic.dts
It seems the D_PSEUDO flag was meant to allow make_dev() to return NULL.
Nowadays we have a different interface for that; make_dev_p(). There's
no need to keep it there.
While there, remove an unneeded D_NEEDMINOR from the gpio driver.
Discussed with: gonzo@ (gpio)
only logged instances where an operation on a file descriptor required
capabilities which the file descriptor did not have. By adding a type enum
to struct ktr_cap_fail, we can catch other types of capability failures as
well, such as disallowed system calls or attempts to wrap a file descriptor
with more capabilities than it had to begin with.
Some earlier series (~AR5212?) play badly with BIOSes.
In these instances, they may require a forced reset (by transitioning
the NIC through D0 -> D3 -> D0) before they probe/attach correctly.
This is currently disabled because:
* I haven't figured out the "right" code to ensure this only happens
for PCI NICs (not PCIe or Cardbus);
* I haven't at all done wide scale testing for this, and I'm not yet
ready for said wide-scale testing.
I'm documenting this primarily so users with misbehaving NICs have
something to tinker with.
Obtained from: Atheros
The final missing bit here is enabling the PCI configuration register
read, but there's currently no glue available for the HAL to read (and
write) PCI configuration space registers.
Obtained from: Atheros
The AR5008/AR9001 series NICs have a bug where BB register reads
will occasionally be corrupted. This could cause issues with things
such as ANI, which adjust operational parameters based on the
BB radio register reads. This was introduced in the AR5008 chip
and fixed with the first released AR9002 series NIC (AR9280v2.)
A followup commit will implement the acutal WAR when reading
BB registers. I'm still not sure how I'll implement it - whether
it should be done in the osdep layer, or whether it should just
live in the AR5416 HAL. Either way, they can use this capability
bit to determine whether to implement the WAR or not.
Thankyou to various sources inside Atheros who have helped me track
down what this particular issue is.
Obtained from: Atheros
There are HAL methods which are actually direct register
access, rather than simply HAL calls. Because of this, these
register accesses would use the non-debug path in ah_osdep.h
as opt_ah.h isn't included.
With this, the correct register access methods are used,
so debugging traces show things such as TXDP checking and
TSF32 access.
When calculating space needed for SA_BONUS buffers,
hdrsize is always rounded up to next 8-aligned boundary.
However, in two places the round up was done against
sum of 'total' plus hdrsize. On the other hand,
hdrsize increments by 4 each time, which means in
certain conditions, we would end up returning with
will_spill == 0 and (total + hdrsize) larger than
full_space, leading to a failed assertion because
it's invalid for dmu_set_bonus.
Sponsored by: iXsystems, Inc.
Reviewed by: mm
MFC after: 3 days
Because driver is accessing a common MII structure in
mii_pollstat(), updating user supplied structure should be done
before dropping a driver lock.
Reported by: Karim (fodillemlinkarimi <> gmail dot com)
Because driver is accessing a common MII structure in
mii_pollstat(), updating user supplied structure should be done
before dropping a driver lock.
Reported by: Karim (fodillemlinkarimi <> gmail dot com)
That way the radar errors aren't enabled prematurely.
A DFS tester has reported that radar events are reported
during channel scanning, before DFS is actually enabled.
Use the offset into the device tree from fdtp as the phandle instead
of using pointer into the device tree. This will make sure that the
phandle fits into a uint32_t type, even when compiled for 64bit.
Reviewed by: raj, nathanw, marcel
on the largest multi-write size.
From the submitter:
==
I looked further into the magic 88-byte threshold after which the bug
occurs. It turns out that figure included the 24-byte tx_desc, and up
to 64 bytes of beacon frame (header+data).
rum_write_multi doesn't seem happy with writing >64 bytes at a time to
the MAC register. If I break it up into separate calls (e.g. bytes
0-63, then bytes 64-65, written at the appropriate offset) I see the
proper beacon frames being transmitted now.
==
Submitted by: Steven Chamberlain <steven@pyro.eu.org>
MFC after: 3 days
