Re: svn commit: r252032 - head/sys/amd64/include

2013-06-25 Thread Konstantin Belousov
On Tue, Jun 25, 2013 at 12:45:36PM +1000, Bruce Evans wrote:
 On Mon, 24 Jun 2013, Konstantin Belousov wrote:
 
  On Sun, Jun 23, 2013 at 07:57:57PM +1000, Bruce Evans wrote:
  The case that can't be fixed by rereading the counters is when fetching
  code runs in between the stores.  If the stores are on a another CPU
  that is currently executing them, then we can keep checking that the
  counters don't change for the maximum time that any pair of stores
  take to complete.  This time is quite long and difficult to determine
  (but it can be bounded by hard-disabling interrupts in the storer, and
  limited by prefetching).  If the stores are on the same CPU, then we
  have no good way to detect that another thread is in the middle of
  them, or to switch back to that thread.  So we currently prevent this
  case using slow methods.
 
  We are already explicit about the fetched value potentially not
  reflecting any real moment value, but indeed, having the fetch result
  off by 2^32 is not acceptable.
 
  We need atomic 64bit loads to fix this, which is provided by the same
  cmpxchg8b instruction on the 8-byte aligned elements.  Intel guarantees
  that 8-byte aligned loads and stores are atomic.
 
  The following is the prototype for the x86. The other 64bit
  architectures are handled exactly like amd64. For 32bit !x86 arches,
  i.e. arm, mips32 and powerpc32, some more investigation is needed.
 
 That works of course, but is too complicated, machine-dependent and slow
 for me.
 (I just checked all the pcpu.h implementations and found that
  all of them except amd64 and i386 still use the quick and racy
  PCPU_PTR(member) += (value) for PCPU_ADD().  This has 1 sure
  race and 1 compiler/machine-dependent race:
  - PCPU_PTR() is only usable if preemption (resulting in rescheduling
to run on a different CPU) is prevented in the caller.  Otherwise,
the pointer may become invalid immediately iafter it is initialized.
  - the compiler may generate a racy load-add-store operation for +=.
Using PCPU_PTR() makes this a smaller problem than using a thread-
local pointer.  It prevents the store going to a different CPU
than the load.
  PCPU_GET() and PCPU_SET() have the first of these problems on all
  arches except amd64 and i386.  Even curthread wouldn't work in the
  SMP case if it has the default implementation of PCPU_GET(curthread).
  However, it has a non-default implementation on all arches except
  arm and mips.  So even curthread seems to be broken for arm and mips.)
Brokeness (or, from other PoV, a restriction on use of PCPU_GET/SET/INC)
is well-known. For ARM, I believe the in-tree kernels do not support SMP
at all, so curthread as is is not broken. For mips it seems as if the
pcpup located on the wired page which mapping is context-switched, that
should make the curthread functional.

 
 The non-optimized machine/counter.h avoids these problems using a
 critical section.  I'm not sure that works.  Anyway, counter.h shouldn't
 have to understand pcpu better than pcpu.h does in order to work.
Updates to the counter cannot be done from the interrupt context.
The fetch problem of sometime missing the carry bit is present on all 
32bit arches now, I think.

 
 The arm implementation of atomic.h is also relevant and is especially
 interesting.  I looked at it after mdf@ pointed out ARM_RAS_START.
 This seems to only be used by arm in userland.  It is even larger and
 slower and more complicated than critical sections, so it doesn't seem
 to be useful for counters.  In the kernel, arm has several
 implementations depending on machine capabilities.  The ifdefs are
 hard to understand.  On some machine, it seems to use the equivalent
 of a cmpxchg loop.  On others, it just disables interrupts.  Disabling
 interrupts is presumably better than a critical section, and userland
 has to use ARM_RAS_START for some arches because neither disabling
 interrupts not critical sections are available in userland.  None
 of this care helps avoid the races in pcpu.h, since pcpu.h intentionally
 avoids using atomic ops.  None of this care helps avoid the races in
 counter.h or make counter.h efficient, since counter.h uses its own
 methods.  To reach the same quality as atomic.h, counter.h would have
 to copy half of the ifdefs and methods in atomic.h.
BTW, why do you claim that disabling interrupts is faster and better method
to disable preemption than critical section ?

 
 The slowness that I care about is only in the counter update.  Anything
 complicated there will be slow.
 
 My current best design:
 - use ordinary mutexes to protect counter fetches in non-per-CPU contexts.
 - use native-sized or always 32-bit counters.  Counter updates are done
by a single addl on i386.  Fix pcpu.h on arches other than amd64 and
i386 and use the same method as there.
 - 

svn commit: r252196 - in head: share/man/man4 sys/dev/usb sys/dev/usb/wlan

2013-06-25 Thread Kevin Lo
Author: kevlo
Date: Tue Jun 25 06:43:04 2013
New Revision: 252196
URL: http://svnweb.freebsd.org/changeset/base/252196

Log:
  Add support for D-Link DWA-131.

Modified:
  head/share/man/man4/urtwn.4
  head/sys/dev/usb/usbdevs
  head/sys/dev/usb/wlan/if_urtwn.c

Modified: head/share/man/man4/urtwn.4
==
--- head/share/man/man4/urtwn.4 Tue Jun 25 05:05:10 2013(r252195)
+++ head/share/man/man4/urtwn.4 Tue Jun 25 06:43:04 2013(r252196)
@@ -74,6 +74,7 @@ The following adapters should work:
 .Pp
 .Bl -tag -width Ds -offset indent -compact
 .It Belkin F7D1102 Surf Wireless Micro
+.It D-Link DWA-131
 .It Edimax EW-7811Un
 .It Netgear WNA1000M
 .It Realtek RTL8192CU

Modified: head/sys/dev/usb/usbdevs
==
--- head/sys/dev/usb/usbdevsTue Jun 25 05:05:10 2013(r252195)
+++ head/sys/dev/usb/usbdevsTue Jun 25 06:43:04 2013(r252196)
@@ -1545,6 +1545,7 @@ product DLINK RTL8188CU   0x3308  RTL8188C
 productDLINK RTL8192CU_1   0x3307  RTL8192CU
 productDLINK RTL8192CU_2   0x3309  RTL8192CU
 productDLINK RTL8192CU_3   0x330a  RTL8192CU
+productDLINK DWA131B   0x330d  DWA-131 rev B
 product DLINK2 DWA120  0x3a0c  DWA-120
 product DLINK2 DWA120_NF   0x3a0d  DWA-120 (no firmware)
 product DLINK2 DWLG122C1   0x3c03  DWL-G122 c1

Modified: head/sys/dev/usb/wlan/if_urtwn.c
==
--- head/sys/dev/usb/wlan/if_urtwn.cTue Jun 25 05:05:10 2013
(r252195)
+++ head/sys/dev/usb/wlan/if_urtwn.cTue Jun 25 06:43:04 2013
(r252196)
@@ -106,6 +106,7 @@ static const STRUCT_USB_HOST_ID urtwn_de
URTWN_DEV(DLINK,RTL8192CU_1),
URTWN_DEV(DLINK,RTL8192CU_2),
URTWN_DEV(DLINK,RTL8192CU_3),
+   URTWN_DEV(DLINK,DWA131B),
URTWN_DEV(EDIMAX,   EW7811UN),
URTWN_DEV(EDIMAX,   RTL8192CU),
URTWN_DEV(FEIXUN,   RTL8188CU),
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252200 - head/etc/devd

2013-06-25 Thread Kevin Lo
Author: kevlo
Date: Tue Jun 25 07:17:30 2013
New Revision: 252200
URL: http://svnweb.freebsd.org/changeset/base/252200

Log:
  Regenerate usb.conf after r252196.
  
  Spotted by:   rpaulo

Modified:
  head/etc/devd/usb.conf

Modified: head/etc/devd/usb.conf
==
--- head/etc/devd/usb.conf  Tue Jun 25 07:17:10 2013(r252199)
+++ head/etc/devd/usb.conf  Tue Jun 25 07:17:30 2013(r252200)
@@ -4299,7 +4299,7 @@ nomatch 32 {
match bus uhub[0-9]+;
match mode host;
match vendor 0x2001;
-   match product (0x3307|0x3308|0x3309|0x330a);
+   match product (0x3307|0x3308|0x3309|0x330a|0x330d);
action kldload -n if_urtwn;
 };
 
@@ -4976,5 +4976,5 @@ nomatch 32 {
action kldload -n umass;
 };
 
-# 2479 USB entries processed
+# 2480 USB entries processed
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252203 - head/sys/dev/ata/chipsets

2013-06-25 Thread Alexander Motin
Author: mav
Date: Tue Jun 25 09:15:49 2013
New Revision: 252203
URL: http://svnweb.freebsd.org/changeset/base/252203

Log:
  Add test for SATA registers writability and skip using them if it failed.
  
  There are some systems reported, where PCI BAR(5), used for SATA registers
  access, is present, but not functional.  Attempt to use it brakes devices
  detection logic.  Try to detect those cases on attach by setting and testing
  some bits in SControl register.  If bits are unsettable, fallback to legacy
  ATA without hot-plug detection, speed control/reporting, etc.
  
  MFC after:2 weeks

Modified:
  head/sys/dev/ata/chipsets/ata-intel.c

Modified: head/sys/dev/ata/chipsets/ata-intel.c
==
--- head/sys/dev/ata/chipsets/ata-intel.c   Tue Jun 25 07:32:49 2013
(r252202)
+++ head/sys/dev/ata/chipsets/ata-intel.c   Tue Jun 25 09:15:49 2013
(r252203)
@@ -72,6 +72,7 @@ static int ata_intel_sata_cscr_write(dev
 int reg, u_int32_t result);
 static int ata_intel_sata_sidpr_write(device_t dev, int port,
 int reg, u_int32_t result);
+static int ata_intel_sata_sidpr_test(device_t dev);
 static int ata_intel_31244_ch_attach(device_t dev);
 static int ata_intel_31244_ch_detach(device_t dev);
 static int ata_intel_31244_status(device_t dev);
@@ -416,22 +417,20 @@ ata_intel_ch_attach(device_t dev)
}
if (ch-flags  ATA_SATA) {
if ((ctlr-chip-cfg1  INTEL_ICH5)) {
-   ch-flags |= ATA_PERIODIC_POLL;
-   ch-hw.status = ata_intel_sata_status;
ch-hw.pm_read = ata_intel_sata_cscr_read;
ch-hw.pm_write = ata_intel_sata_cscr_write;
} else if (ctlr-r_res2) {
-   ch-flags |= ATA_PERIODIC_POLL;
-   ch-hw.status = ata_intel_sata_status;
if ((ctlr-chip-cfg1  INTEL_ICH7)) {
ch-hw.pm_read = 
ata_intel_sata_ahci_read;
ch-hw.pm_write = 
ata_intel_sata_ahci_write;
-   } else {
+   } else if (ata_intel_sata_sidpr_test(dev)) {
ch-hw.pm_read = 
ata_intel_sata_sidpr_read;
ch-hw.pm_write = 
ata_intel_sata_sidpr_write;
};
}
if (ch-hw.pm_write != NULL) {
+   ch-flags |= ATA_PERIODIC_POLL;
+   ch-hw.status = ata_intel_sata_status;
ata_sata_scr_write(ch, 0,
ATA_SERROR, 0x);
if ((ch-flags  ATA_NO_SLAVE) == 0) {
@@ -835,6 +834,32 @@ ata_intel_sata_sidpr_write(device_t dev,
 }
 
 static int
+ata_intel_sata_sidpr_test(device_t dev)
+{
+   struct ata_channel *ch = device_get_softc(dev);
+   int port;
+   uint32_t val;
+
+   port = (ch-flags  ATA_NO_SLAVE) ? 0 : 1;
+   for (; port = 0; port--) {
+   ata_intel_sata_sidpr_read(dev, port, ATA_SCONTROL, val);
+   if ((val  ATA_SC_IPM_MASK) ==
+   (ATA_SC_IPM_DIS_PARTIAL | ATA_SC_IPM_DIS_SLUMBER))
+   return (1);
+   val |= ATA_SC_IPM_DIS_PARTIAL | ATA_SC_IPM_DIS_SLUMBER;
+   ata_intel_sata_sidpr_write(dev, port, ATA_SCONTROL, val);
+   ata_intel_sata_sidpr_read(dev, port, ATA_SCONTROL, val);
+   if ((val  ATA_SC_IPM_MASK) ==
+   (ATA_SC_IPM_DIS_PARTIAL | ATA_SC_IPM_DIS_SLUMBER))
+   return (1);
+   }
+   if (bootverbose)
+   device_printf(dev,
+   SControl registers are not functional: %08x\n, val);
+   return (0);
+}
+
+static int
 ata_intel_31244_ch_attach(device_t dev)
 {
 struct ata_pci_controller *ctlr = device_get_softc(device_get_parent(dev));
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r252032 - head/sys/amd64/include

2013-06-25 Thread Bruce Evans

On Tue, 25 Jun 2013, Konstantin Belousov wrote:


On Tue, Jun 25, 2013 at 12:45:36PM +1000, Bruce Evans wrote:

On Mon, 24 Jun 2013, Konstantin Belousov wrote:

...

The following is the prototype for the x86. The other 64bit
architectures are handled exactly like amd64. For 32bit !x86 arches,
i.e. arm, mips32 and powerpc32, some more investigation is needed.


That works of course, but is too complicated, machine-dependent and slow
for me.
...
The non-optimized machine/counter.h avoids these problems using a
critical section.  I'm not sure that works.  Anyway, counter.h shouldn't
have to understand pcpu better than pcpu.h does in order to work.

Updates to the counter cannot be done from the interrupt context.


This is fragile, however.  It prevents using counters for things like
counting interrupts.  Most interrupt counting is now done directlyly
and doesn't use PCPU_INC().  i386/i386 has just 1 use of PCPU_INC().
It is to count traps in machdep.c.  Traps include nonmaskable
interrupts.  Even hard-disabling of interrupts doesn't prevent these.
Otherwise, PCPU is used mainly for vm counters.  E.g., for pagefaults.
Now the trap is not an interrupt, so it shouldn't occur in the middle
of the counter update and the PCPU_INC() can safely be replaced by
a counter, but this is not clear.


The fetch problem of sometime missing the carry bit is present on all
32bit arches now, I think.


Also the zeroing problem.  Since there are no atomic ops in sight, zeroing
has several races.  My transferring code uses atomic ops on only 1 CPU,
so it has half of these races.  See below.


The arm implementation of atomic.h is also relevant and is especially
interesting.  I looked at it after mdf@ pointed out ARM_RAS_START.
This seems to only be used by arm in userland.  It is even larger and
slower and more complicated than critical sections, so it doesn't seem
to be useful for counters.  In the kernel, arm has several
implementations depending on machine capabilities.  The ifdefs are
hard to understand.  On some machine, it seems to use the equivalent
of a cmpxchg loop.  On others, it just disables interrupts.  Disabling
interrupts is presumably better than a critical section, and userland
has to use ARM_RAS_START for some arches because neither disabling
interrupts not critical sections are available in userland.  None
of this care helps avoid the races in pcpu.h, since pcpu.h intentionally
avoids using atomic ops.  None of this care helps avoid the races in
counter.h or make counter.h efficient, since counter.h uses its own
methods.  To reach the same quality as atomic.h, counter.h would have
to copy half of the ifdefs and methods in atomic.h.

BTW, why do you claim that disabling interrupts is faster and better method
to disable preemption than critical section ?


For arm, it is because if the critical section method were better, then
arm should use it for atomic ops too.

For i386, it is because it reduces the window in which the value is invalid
(other CPUs can see the invalid value), and is easier to use and shorter
(2-3 bytes) and thus better suited to inline code.  My examples of inline
code mostly used it in rarely-executed cases where its speed doesn't matter
and it is just easier to use.  Actual testing shows that it is fairly
efficient, so can be used in all cases.  On Athlon64, it is faster than
cmpxchg8b but slower than an inline optimized critical section.  This
testing is in userland, where there may be an extra penalty for using
cli/sti/pushfl/popfl:

% static inline void
% counter_u64_add(counter_u64_t c, int64_t inc)
% {
% 
% #if 1

%   /* 20 cycles on A64. */
%   /* 31 cycles on A64 with lock prefix. */
%   /* 35 cycles on A64 with mfence prefix. */
%   if ((cpu_feature  1) == 1) {
%   counter_64_inc_8b(c, inc);
%   }

Old tests said that this takes 18 cycles.  It now takes 20.

Adding a lock or mfence prefix to the cmpxchg8b gives the times stated
above.  This shows how bad using cmpxch8b is.  We could use atomic ops
for everything and only be 50% slower.  But we shouldn't use either
cmpxchg8b or atomic ops.  We should use 32-bit addl, which takes about
4 cycles.

% struct thread
% {
%   uint32_t td_critnest;
%   uint32_t td_owepreempt;
% } td0;
% 
% volatile struct thread *td = td0;
% 
% void

% dummy_accum(void)
% {
% }
% 
% void

% fake_mi_switch(void)
% {
% }

Added more emulation for a complete critical section emulation.

% static inline void
% alt_counter_u64_add(counter_u64_t c, int64_t inc)
% {
% #if 0
%   /* 8.5 cycles on A64. */
%   td-td_critnest++;
%   __asm __volatile(addl %1,%%ds:%0 : =m,m (*c) : ?i,r (inc));
%   td-td_critnest++;
% #elif 0
%   /* 7 cycles on A64. */
%   uint32_t ocritnest;
% 
% 	ocritnest = td-td_critnest;

%   td-td_critnest = ocritnest + 1;
%   __asm __volatile(addl %1,%%ds:%0 : =m,m (*c) : ?i,r (inc));
%   

svn commit: r252204 - head/sys/cam/scsi

2013-06-25 Thread Alexander Motin
Author: mav
Date: Tue Jun 25 10:50:17 2013
New Revision: 252204
URL: http://svnweb.freebsd.org/changeset/base/252204

Log:
  Add bunch of names for Seagate and HGST vennor-specififc ASC/ASCQ codes.

Modified:
  head/sys/cam/scsi/scsi_all.c

Modified: head/sys/cam/scsi/scsi_all.c
==
--- head/sys/cam/scsi/scsi_all.cTue Jun 25 09:15:49 2013
(r252203)
+++ head/sys/cam/scsi/scsi_all.cTue Jun 25 10:50:17 2013
(r252204)
@@ -737,6 +737,172 @@ static struct asc_table_entry sony_mo_en
 Logical unit not ready, cause not reportable) }
 };
 
+static struct asc_table_entry hgst_entries[] = {
+   { SST(0x04, 0xF0, SS_RDEF,
+   Vendor Unique - Logical Unit Not Ready) },
+   { SST(0x0A, 0x01, SS_RDEF,
+   Unrecovered Super Certification Log Write Error) },
+   { SST(0x0A, 0x02, SS_RDEF,
+   Unrecovered Super Certification Log Read Error) },
+   { SST(0x15, 0x03, SS_RDEF,
+   Unrecovered Sector Error) },
+   { SST(0x3E, 0x04, SS_RDEF,
+   Unrecovered Self-Test Hard-Cache Test Fail) },
+   { SST(0x3E, 0x05, SS_RDEF,
+   Unrecovered Self-Test OTF-Cache Fail) },
+   { SST(0x40, 0x00, SS_RDEF,
+   Unrecovered SAT No Buffer Overflow Error) },
+   { SST(0x40, 0x01, SS_RDEF,
+   Unrecovered SAT Buffer Overflow Error) },
+   { SST(0x40, 0x02, SS_RDEF,
+   Unrecovered SAT No Buffer Overflow With ECS Fault) },
+   { SST(0x40, 0x03, SS_RDEF,
+   Unrecovered SAT Buffer Overflow With ECS Fault) },
+   { SST(0x40, 0x81, SS_RDEF,
+   DRAM Failure) },
+   { SST(0x44, 0x0B, SS_RDEF,
+   Vendor Unique - Internal Target Failure) },
+   { SST(0x44, 0xF2, SS_RDEF,
+   Vendor Unique - Internal Target Failure) },
+   { SST(0x44, 0xF6, SS_RDEF,
+   Vendor Unique - Internal Target Failure) },
+   { SST(0x44, 0xF9, SS_RDEF,
+   Vendor Unique - Internal Target Failure) },
+   { SST(0x44, 0xFA, SS_RDEF,
+   Vendor Unique - Internal Target Failure) },
+   { SST(0x5D, 0x22, SS_RDEF,
+   Extreme Over-Temperature Warning) },
+   { SST(0x5D, 0x50, SS_RDEF,
+   Load/Unload cycle Count Warning) },
+   { SST(0x81, 0x00, SS_RDEF,
+   Vendor Unique - Internal Logic Error) },
+   { SST(0x85, 0x00, SS_RDEF,
+   Vendor Unique - Internal Key Seed Error) },
+};
+
+static struct asc_table_entry seagate_entries[] = {
+   { SST(0x04, 0xF0, SS_RDEF,
+   Logical Unit Not Ready, super certify in Progress) },
+   { SST(0x08, 0x86, SS_RDEF,
+   Write Fault Data Corruption) },
+   { SST(0x09, 0x0D, SS_RDEF,
+   Tracking Failure) },
+   { SST(0x09, 0x0E, SS_RDEF,
+   ETF Failure) },
+   { SST(0x0B, 0x5D, SS_RDEF,
+   Pre-SMART Warning) },
+   { SST(0x0B, 0x85, SS_RDEF,
+   5V Voltage Warning) },
+   { SST(0x0B, 0x8C, SS_RDEF,
+   12V Voltage Warning) },
+   { SST(0x0C, 0xFF, SS_RDEF,
+   Write Error – Too many error recovery revs) },
+   { SST(0x11, 0xFF, SS_RDEF,
+   Unrecovered Read Error – Too many error recovery revs) },
+   { SST(0x19, 0x0E, SS_RDEF,
+   Fewer than 1/2 defect list copies) },
+   { SST(0x20, 0xF3, SS_RDEF,
+   Illegal CDB linked to skip mask cmd) },
+   { SST(0x24, 0xF0, SS_RDEF,
+   Illegal byte in CDB, LBA not matching) },
+   { SST(0x24, 0xF1, SS_RDEF,
+   Illegal byte in CDB, LEN not matching) },
+   { SST(0x24, 0xF2, SS_RDEF,
+   Mask not matching transfer length) },
+   { SST(0x24, 0xF3, SS_RDEF,
+   Drive formatted without plist) },
+   { SST(0x26, 0x95, SS_RDEF,
+   Invalid Field Parameter – CAP File) },
+   { SST(0x26, 0x96, SS_RDEF,
+   Invalid Field Parameter – RAP File) },
+   { SST(0x26, 0x97, SS_RDEF,
+   Invalid Field Parameter – TMS Firmware Tag) },
+   { SST(0x26, 0x98, SS_RDEF,
+   Invalid Field Parameter – Check Sum) },
+   { SST(0x26, 0x99, SS_RDEF,
+   Invalid Field Parameter – Firmware Tag) },
+   { SST(0x29, 0x08, SS_RDEF,
+   Write Log Dump data) },
+   { SST(0x29, 0x09, SS_RDEF,
+   Write Log Dump data) },
+   { SST(0x29, 0x0A, SS_RDEF,
+   Reserved disk space) },
+   { SST(0x29, 0x0B, SS_RDEF,
+   SDBP) },
+   { SST(0x29, 0x0C, SS_RDEF,
+   SDBP) },
+   { SST(0x31, 0x91, SS_RDEF,
+   Format Corrupted World Wide Name (WWN) is Invalid) },
+   { SST(0x32, 0x03, SS_RDEF,
+   Defect List – Length exceeds Command Allocated Length) },
+   { SST(0x33, 0x00, SS_RDEF,
+   Flash not ready for access) },
+   { SST(0x3F, 0x70, SS_RDEF,
+   Invalid RAP block) },
+   { SST(0x3F, 0x71, SS_RDEF,
+   RAP/ETF mismatch) },
+   { SST(0x3F, 

Re: svn commit: r252032 - head/sys/amd64/include

2013-06-25 Thread Gleb Smirnoff
On Mon, Jun 24, 2013 at 11:16:33PM +1000, Bruce Evans wrote:
B  K This is quite interesting idea, but I still did not decided if it
B  K acceptable.  The issue is that we could add the carry to the other
B  K processor counter, if the preemption kicks in at right time between
B  K two instructions.  I did not found any argument why would it be
B  K wrong, the races for fetch operation seems to be the same with either
B  K local update method.
B 
B  This would be wrong since update isn't locked. Thus, if we are put on
B  other CPU between two instructions, and in second instruction updating
B  another CPU counter simultaneously with the original CPU we were on,
B  then we are losing an update.
B 
B Hmm, this is subtle.  The update is never lost, but is applied to
B different counter, non-atomically at a later time.  Non-atomicity
B only matters when there is a carry since the counter only goes
B transiently backards in this case.  For example: initial state:
B 
B  CPU1 counter:   
B  CPU2 counter:   fffe
B 
B Start adding 1 to the first counter, doing it non-atomically by
B incrementing the low word first.
B 
B  CPU1 counter:     (carry in CPU1 eflags)
B  CPU2 counter:   fffe
B 
B Get preempted at this point:
B 
B  CPU1 counter:   
B  CPU2 counter:   fffe  (carry in CPU2 eflags)

Nope, the non-atomicity isn't specific to the case when we carry
bit from least significant part to most one.

The non-atomicity is much simplier: two CPUs write to same memory address
w/o using lock prefix.

Thus, any update mechanism that first calculates absolute per-CPU address,
then writes to it w/o lock, requires critical section. Because preemption
between calculation and write, and later execution on other CPU leads
to two CPUs writing to same address.

-- 
Totus tuus, Glebius.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r252184 - head/sys/net

2013-06-25 Thread Slawa Olhovchenkov
On Tue, Jun 25, 2013 at 12:10:50AM +, Qing Li wrote:

 Author: qingli
 Date: Tue Jun 25 00:10:49 2013
 New Revision: 252184
 URL: http://svnweb.freebsd.org/changeset/base/252184
 
 Log:
   Due to the routing related networking kernel redesign work
   in FBSD 8.0, interface routes have been returened to the
   applications without the RTF_GATEWAY bit. This incompatibility
   has caused some issues with Zebra, Qugga and the like.
   This patch provides the RTF_GATEWAY flag bit in returned interface
   routes so to behave similarly to pre 8.0 systems.
   
   Reviewed by:hrs
   Verified by:mackn at opendns dot com
 
 Modified:
   head/sys/net/route.h
   head/sys/net/rtsock.c

MFC planed?
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r252032 - head/sys/amd64/include

2013-06-25 Thread Bruce Evans

On Tue, 25 Jun 2013, Gleb Smirnoff wrote:


On Mon, Jun 24, 2013 at 11:16:33PM +1000, Bruce Evans wrote:
B  K This is quite interesting idea, but I still did not decided if it
B  K acceptable.  The issue is that we could add the carry to the other
B  K processor counter, if the preemption kicks in at right time between
B  K two instructions.  I did not found any argument why would it be
B  K wrong, the races for fetch operation seems to be the same with either
B  K local update method.
B 
B  This would be wrong since update isn't locked. Thus, if we are put on
B  other CPU between two instructions, and in second instruction updating
B  another CPU counter simultaneously with the original CPU we were on,
B  then we are losing an update.
B
B Hmm, this is subtle.  The update is never lost, but is applied to
B different counter, non-atomically at a later time.  Non-atomicity
B only matters when there is a carry since the counter only goes
B transiently backards in this case.  For example: initial state:
B
B  CPU1 counter:   
B  CPU2 counter:   fffe
B
B Start adding 1 to the first counter, doing it non-atomically by
B incrementing the low word first.
B
B  CPU1 counter:     (carry in CPU1 eflags)
B  CPU2 counter:   fffe
B
B Get preempted at this point:
B
B  CPU1 counter:   
B  CPU2 counter:   fffe  (carry in CPU2 eflags)

Nope, the non-atomicity isn't specific to the case when we carry
bit from least significant part to most one.


Sure, but the other parts already work correctly.


The non-atomicity is much simplier: two CPUs write to same memory address
w/o using lock prefix.


No, they can't, since these are per-CPU counters.  Except for broken
per-CPU counters and invalid accesses by CPUs that don't own the counter
in upper layer code.


Thus, any update mechanism that first calculates absolute per-CPU address,
then writes to it w/o lock, requires critical section. Because preemption
between calculation and write, and later execution on other CPU leads
to two CPUs writing to same address.


Only broken per-CPU counters do that.  I already pointed out that all
arches except amd64 and i386 have buggy PCPU_ADD() and other PCPU_*()
access functions because they do do that.  ia64, powerpc and sparc64
even document that that they do this in an XXX comment.  Actually,
ia64 and sparc64 and perhaps some others are not quite this bad, since
their pcpu pointer is in a special register that should get switched
by context switches.  It still takes a lot of magic for the compiler
to use this register for the accesses and not copy it to another
register that doesn't get context switched.  Their pcpu access bugs
may be limited to the compiler possibly generating non-atomic
load-modify-store instructions.

Their XXX comment has wording bugs either way.  It says that this
operation should be made atomic, but the scope of the comment is 4
operations.  The first operation is PCPU_ADD(), and it used to be the
only one that does load-modify-store.  Now it is followed by the
PCPU_INC() operation which also does load-modify-store.  Aligned word-sized
operations have a chance of being atomic enough for the other operations.

Bruce
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252205 - head/etc/periodic/daily

2013-06-25 Thread John Baldwin
Author: jhb
Date: Tue Jun 25 15:45:31 2013
New Revision: 252205
URL: http://svnweb.freebsd.org/changeset/base/252205

Log:
  If daily_status_security_inline is set, the rc value needs to be
  forced to 3 so that the output of this script is always displayed.
  In fact, setting this flag is identical to setting
  daily_status_security_output to an empty string.  To make the logic
  less confusing, change the behavior of daily_status_security_inline
  such that it just forces daily_status_security_output to an empty
  string and then applies the normal logic.
  
  PR:   conf/178611
  Submitted by: Jason Unovitch jason.unovi...@gmail.com
  MFC after:3 days

Modified:
  head/etc/periodic/daily/450.status-security

Modified: head/etc/periodic/daily/450.status-security
==
--- head/etc/periodic/daily/450.status-security Tue Jun 25 10:50:17 2013
(r252204)
+++ head/etc/periodic/daily/450.status-security Tue Jun 25 15:45:31 2013
(r252205)
@@ -18,19 +18,19 @@ case $daily_status_security_enable in
 
case $daily_status_security_inline in
[Yy][Ee][Ss])
-   export security_output=;;
+   daily_status_security_output=;;
+   esac
+
+   export security_output=${daily_status_security_output}
+   case ${daily_status_security_output} in
+   )
+   rc=3;;
+   /*)
+   echo (output logged separately)
+   rc=0;;
*)
-   export security_output=${daily_status_security_output}
-   case ${daily_status_security_output} in
-   )
-   rc=3;;
-   /*)
-   echo (output logged separately)
-   rc=0;;
-   *)
-   echo (output mailed separately)
-   rc=0;;
-   esac;;
+   echo (output mailed separately)
+   rc=0;;
esac
 
periodic security || rc=3;;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252206 - in head: share/man/man4 sys/conf sys/dev/qlxge sys/modules sys/modules/qlxge

2013-06-25 Thread David C Somayajulu
Author: davidcs
Date: Tue Jun 25 17:50:22 2013
New Revision: 252206
URL: http://svnweb.freebsd.org/changeset/base/252206

Log:
  Add Qlogic 10Gb Ethernet Driver for Qlogic 8100 Series CNA Adapter
  Driver version (v2.0.0)
  
  Submitted by: David C Somayajulu (davi...@freebsd.org) QLogic Corporation
  Approved by: George Neville-Neil (g...@freebsd.org)

Added:
  head/share/man/man4/qlxge.4   (contents, props changed)
  head/sys/dev/qlxge/
  head/sys/dev/qlxge/README.txt   (contents, props changed)
  head/sys/dev/qlxge/qls_dbg.c   (contents, props changed)
  head/sys/dev/qlxge/qls_dbg.h   (contents, props changed)
  head/sys/dev/qlxge/qls_def.h   (contents, props changed)
  head/sys/dev/qlxge/qls_dump.c   (contents, props changed)
  head/sys/dev/qlxge/qls_dump.h   (contents, props changed)
  head/sys/dev/qlxge/qls_glbl.h   (contents, props changed)
  head/sys/dev/qlxge/qls_hw.c   (contents, props changed)
  head/sys/dev/qlxge/qls_hw.h   (contents, props changed)
  head/sys/dev/qlxge/qls_inline.h   (contents, props changed)
  head/sys/dev/qlxge/qls_ioctl.c   (contents, props changed)
  head/sys/dev/qlxge/qls_ioctl.h   (contents, props changed)
  head/sys/dev/qlxge/qls_isr.c   (contents, props changed)
  head/sys/dev/qlxge/qls_os.c   (contents, props changed)
  head/sys/dev/qlxge/qls_os.h   (contents, props changed)
  head/sys/dev/qlxge/qls_ver.h   (contents, props changed)
  head/sys/modules/qlxge/
  head/sys/modules/qlxge/Makefile   (contents, props changed)
Modified:
  head/share/man/man4/Makefile
  head/sys/conf/files.amd64
  head/sys/modules/Makefile

Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileTue Jun 25 15:45:31 2013
(r252205)
+++ head/share/man/man4/MakefileTue Jun 25 17:50:22 2013
(r252206)
@@ -371,6 +371,7 @@ MAN=aac.4 \
pts.4 \
pty.4 \
puc.4 \
+   ${_qlxge.4} \
${_qlxgb.4} \
${_qlxgbe.4} \
ral.4 \
@@ -793,10 +794,12 @@ _bhyve.4= bhyve.4
 _if_ntb.4= if_ntb.4
 _ntb.4=ntb.4
 _ntb_hw.4= ntb_hw.4
+_qlxge.4=  qlxge.4
 _qlxgb.4=  qlxgb.4
 _qlxgbe.4= qlxgbe.4
 _sfxge.4=  sfxge.4
 
+MLINKS+=qlxge.4 if_qlxge.4
 MLINKS+=qlxgb.4 if_qlxgb.4
 MLINKS+=qlxgbe.4 if_qlxgbe.4
 MLINKS+=sfxge.4 if_sfxge.4

Added: head/share/man/man4/qlxge.4
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man4/qlxge.4 Tue Jun 25 17:50:22 2013(r252206)
@@ -0,0 +1,91 @@
+.\-
+.\ Copyright (c) 2013-2014 Qlogic Corporation 
+.\ All rights reserved.
+.\
+.\ Redistribution and use in source and binary forms, with or without
+.\ modification, are permitted provided that the following conditions
+.\ are met:
+.\ 1. Redistributions of source code must retain the above copyright
+.\notice, this list of conditions and the following disclaimer.
+.\ 2. Redistributions in binary form must reproduce the above copyright
+.\notice, this list of conditions and the following disclaimer in the
+.\documentation and/or other materials provided with the distribution.
+.\
+.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\ ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\ SUCH DAMAGE.
+.\
+.\ $FreeBSD$
+.\
+.Dd June 21, 2013
+.Dt QLXGE 4
+.Os
+.Sh NAME
+.Nm qlxge
+.Nd QLogic 8100 Series 10 Gigabit Ethernet Adapter Driver
+.Sh SYNOPSIS
+To compile this driver into the kernel,
+place the following lines in your
+kernel configuration file:
+.Bd -ragged -offset indent
+.Cd device qlxge
+.Ed
+.Pp
+To load the driver as a
+module at boot time, place the following line in
+.Xr loader.conf 5 :
+.Bd -literal -offset indent
+if_qlxge_load=YES
+.Ed
+.Sh DESCRIPTION
+The
+.Nm
+driver supports IPv4 checksum offload,
+TCP and UDP checksum offload for both IPv4 and IPv6,
+Large Segment Offload for both IPv4 and IPv6,
+Jumbo frames, VLAN Tag, and
+Receive Side scaling.
+For further hardware information, see
+.Pa http://www.qlogic.com/ .
+.Sh HARDWARE
+The
+.Nm
+driver supports 10 Gigabit Ethernet  CNA Adapter based on the following
+chipsets:
+.Pp
+.Bl -bullet -compact
+.It
+QLogic 8100 series
+.El
+.Sh SUPPORT
+For support questions please contact 

svn commit: r252207 - head/tools/tools/ath

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Tue Jun 25 17:50:48 2013
New Revision: 252207
URL: http://svnweb.freebsd.org/changeset/base/252207

Log:
  Add include path to the ar9300 HAL.

Modified:
  head/tools/tools/ath/Makefile.inc

Modified: head/tools/tools/ath/Makefile.inc
==
--- head/tools/tools/ath/Makefile.inc   Tue Jun 25 17:50:22 2013
(r252206)
+++ head/tools/tools/ath/Makefile.inc   Tue Jun 25 17:50:48 2013
(r252207)
@@ -11,4 +11,5 @@ CFLAGS+=-I${.CURDIR}/../common
 CFLAGS+=-I${.CURDIR}/../../../../sys
 CFLAGS+=-I${.CURDIR}/../../../../sys/dev/ath
 CFLAGS+=-I${.CURDIR}/../../../../sys/dev/ath/ath_hal
+CFLAGS+=-I${.CURDIR}/../../../../sys/contrib/dev/ath/ath_hal
 CFLAGS+=-I${.OBJDIR}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r252184 - head/sys/net

2013-06-25 Thread Adrian Chadd
Is this worth a freebsd version bump? In case some ports rely on the
new-but-now-broken behaviour?


Adrian

On 25 June 2013 06:48, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
 On Tue, Jun 25, 2013 at 12:10:50AM +, Qing Li wrote:

 Author: qingli
 Date: Tue Jun 25 00:10:49 2013
 New Revision: 252184
 URL: http://svnweb.freebsd.org/changeset/base/252184

 Log:
   Due to the routing related networking kernel redesign work
   in FBSD 8.0, interface routes have been returened to the
   applications without the RTF_GATEWAY bit. This incompatibility
   has caused some issues with Zebra, Qugga and the like.
   This patch provides the RTF_GATEWAY flag bit in returned interface
   routes so to behave similarly to pre 8.0 systems.

   Reviewed by:hrs
   Verified by:mackn at opendns dot com

 Modified:
   head/sys/net/route.h
   head/sys/net/rtsock.c

 MFC planed?
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r252184 - head/sys/net

2013-06-25 Thread Slawa Olhovchenkov
On Tue, Jun 25, 2013 at 11:33:31AM -0700, Adrian Chadd wrote:

 Is this worth a freebsd version bump? In case some ports rely on the
 new-but-now-broken behaviour?

I think bird reinstall routes w/o RTF_GATEWAY bit and can't remove
this. I think none relay on returned routes w/o RTF_GATEWAY bit.


 Adrian
 
 On 25 June 2013 06:48, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
  On Tue, Jun 25, 2013 at 12:10:50AM +, Qing Li wrote:
 
  Author: qingli
  Date: Tue Jun 25 00:10:49 2013
  New Revision: 252184
  URL: http://svnweb.freebsd.org/changeset/base/252184
 
  Log:
Due to the routing related networking kernel redesign work
in FBSD 8.0, interface routes have been returened to the
applications without the RTF_GATEWAY bit. This incompatibility
has caused some issues with Zebra, Qugga and the like.
This patch provides the RTF_GATEWAY flag bit in returned interface
routes so to behave similarly to pre 8.0 systems.
 
Reviewed by:hrs
Verified by:mackn at opendns dot com
 
  Modified:
head/sys/net/route.h
head/sys/net/rtsock.c
 
  MFC planed?
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252209 - in head: share/man/man9 sys/kern sys/sys

2013-06-25 Thread John Baldwin
Author: jhb
Date: Tue Jun 25 18:44:15 2013
New Revision: 252209
URL: http://svnweb.freebsd.org/changeset/base/252209

Log:
  Several improvements to rmlock(9).  Many of these are based on patches
  provided by Isilon.
  - Add an rm_assert() supporting various lock assertions similar to other
locking primitives.  Because rmlocks track readers the assertions are
always fully accurate unlike rw_assert() and sx_assert().
  - Flesh out the lock class methods for rmlocks to support sleeping via
condvars and rm_sleep() (but only while holding write locks), rmlock
details in 'show lock' in DDB, and the lc_owner method used by
dtrace.
  - Add an internal destroyed cookie so that API functions can assert
that an rmlock is not destroyed.
  - Make use of rm_assert() to add various assertions to the API (e.g.
to assert locks are held when an unlock routine is called).
  - Give RM_SLEEPABLE locks their own lock class and always use the
rmlock's own lock_object with WITNESS.
  - Use THREAD_NO_SLEEPING() / THREAD_SLEEPING_OK() to disallow sleeping
while holding a read lock on an rmlock.
  
  Submitted by: andre
  Obtained from:EMC/Isilon

Modified:
  head/share/man/man9/Makefile
  head/share/man/man9/rmlock.9
  head/sys/kern/kern_cpuset.c
  head/sys/kern/kern_rmlock.c
  head/sys/kern/subr_lock.c
  head/sys/sys/_rmlock.h
  head/sys/sys/cpuset.h
  head/sys/sys/lock.h
  head/sys/sys/rmlock.h

Modified: head/share/man/man9/Makefile
==
--- head/share/man/man9/MakefileTue Jun 25 17:55:12 2013
(r252208)
+++ head/share/man/man9/MakefileTue Jun 25 18:44:15 2013
(r252209)
@@ -1077,12 +1077,15 @@ MLINKS+=rman.9 rman_activate_resource.9 
rman.9 rman_set_bustag.9 \
rman.9 rman_set_rid.9 \
rman.9 rman_set_virtual.9
-MLINKS+=rmlock.9 rm_destroy.9 \
+MLINKS+=rmlock.9 rm_assert.9 \
+   rmlock.9 rm_destroy.9 \
rmlock.9 rm_init.9 \
+   rmlock.9 rm_init_flags.9 \
rmlock.9 rm_rlock.9 \
-   rmlock.9 rm_try_rlock.9 \
rmlock.9 rm_runlock.9 \
+   rmlock.9 rm_sleep.9 \
rmlock.9 RM_SYSINIT.9 \
+   rmlock.9 rm_try_rlock.9 \
rmlock.9 rm_wlock.9 \
rmlock.9 rm_wowned.9 \
rmlock.9 rm_wunlock.9

Modified: head/share/man/man9/rmlock.9
==
--- head/share/man/man9/rmlock.9Tue Jun 25 17:55:12 2013
(r252208)
+++ head/share/man/man9/rmlock.9Tue Jun 25 18:44:15 2013
(r252209)
@@ -26,7 +26,7 @@
 .\ $FreeBSD$
 .\
 .\ Based on rwlock.9 man page
-.Dd June 8, 2012
+.Dd June 25, 2013
 .Dt RMLOCK 9
 .Os
 .Sh NAME
@@ -40,6 +40,8 @@
 .Nm rm_runlock ,
 .Nm rm_wunlock ,
 .Nm rm_wowned ,
+.Nm rm_sleep ,
+.Nm rm_assert ,
 .Nm RM_SYSINIT
 .Nd kernel reader/writer lock optimized for read-mostly access patterns
 .Sh SYNOPSIS
@@ -64,6 +66,13 @@
 .Fn rm_wunlock struct rmlock *rm
 .Ft int
 .Fn rm_wowned const struct rmlock *rm
+.Ft int
+.Fn rm_sleep void *wchan struct rmlock *rm int priority const char 
*wmesg int timo
+.Pp
+.Cd options INVARIANTS
+.Cd options INVARIANT_SUPPORT
+.Ft void
+.Fn rm_assert struct rmlock *rm int what
 .In sys/kernel.h
 .Fn RM_SYSINIT name struct rmlock *rm const char *desc int opts
 .Sh DESCRIPTION
@@ -215,12 +224,63 @@ lock must be unlocked.
 This function returns a non-zero value if the current thread owns an
 exclusive lock on
 .Fa rm .
+.It Fn rm_sleep void *wchan struct rmlock *rm int priority const char 
*wmesg int timo
+This function atomically releases
+.Fa rm
+while waiting for an event.
+The
+.Fa rm
+lock must be exclusively locked.
+For more details on the parameters to this function,
+see
+.Xr sleep 9 .
+.It Fn rm_assert struct rmlock *rm int what
+This function asserts that the
+.Fa rm
+lock is in the state specified by
+.Fa what .
+If the assertions are not true and the kernel is compiled with
+.Cd options INVARIANTS
+and
+.Cd options INVARIANT_SUPPORT ,
+the kernel will panic.
+Currently the following base assertions are supported:
+.Bl -tag -width .Dv RA_UNLOCKED
+.It Dv RA_LOCKED
+Assert that current thread holds either a shared or exclusive lock
+of
+.Fa rm .
+.It Dv RA_RLOCKED
+Assert that current thread holds a shared lock of
+.Fa rm .
+.It Dv RA_WLOCKED
+Assert that current thread holds an exclusive lock of
+.Fa rm .
+.It Dv RA_UNLOCKED
+Assert that current thread holds neither a shared nor exclusive lock of
+.Fa rm .
+.El
+.Pp
+In addition, one of the following optional flags may be specified with
+.Dv RA_LOCKED ,
+.Dv RA_RLOCKED ,
+or
+.Dv RA_WLOCKED :
+.Bl -tag -width .Dv RA_NOTRECURSED
+.It Dv RA_RECURSED
+Assert that the current thread holds a recursive lock of
+.Fa rm .
+.It Dv RA_NOTRECURSED
+Assert that the current thread does not hold a recursive lock of
+.Fa rm .
+.El
 .El
 .Sh SEE ALSO
 .Xr locking 9 ,
 .Xr mutex 9 ,
 .Xr panic 9 ,
 .Xr rwlock 9 ,
+.Xr sleep 9 ,
 .Xr 

svn commit: r252212 - head/sys/kern

2013-06-25 Thread John Baldwin
Author: jhb
Date: Tue Jun 25 20:23:08 2013
New Revision: 252212
URL: http://svnweb.freebsd.org/changeset/base/252212

Log:
  A few mostly cosmetic nits to aid in debugging:
  - Call lock_init() first before setting any lock_object fields in
lock init routines.  This way if the machine panics due to a duplicate
init the lock's original state is preserved.
  - Somewhat similarly, don't decrement td_locks and td_slocks until after
an unlock operation has completed successfully.

Modified:
  head/sys/kern/kern_lock.c
  head/sys/kern/kern_mutex.c
  head/sys/kern/kern_rwlock.c
  head/sys/kern/kern_sx.c

Modified: head/sys/kern/kern_lock.c
==
--- head/sys/kern/kern_lock.c   Tue Jun 25 20:03:06 2013(r252211)
+++ head/sys/kern/kern_lock.c   Tue Jun 25 20:23:08 2013(r252212)
@@ -238,8 +238,6 @@ wakeupshlk(struct lock *lk, const char *
u_int realexslp;
int queue, wakeup_swapper;
 
-   TD_LOCKS_DEC(curthread);
-   TD_SLOCKS_DEC(curthread);
WITNESS_UNLOCK(lk-lock_object, 0, file, line);
LOCK_LOG_LOCK(SUNLOCK, lk-lock_object, 0, 0, file, line);
 
@@ -339,6 +337,8 @@ wakeupshlk(struct lock *lk, const char *
}
 
lock_profile_release_lock(lk-lock_object);
+   TD_LOCKS_DEC(curthread);
+   TD_SLOCKS_DEC(curthread);
return (wakeup_swapper);
 }
 
@@ -397,12 +397,12 @@ lockinit(struct lock *lk, int pri, const
iflags |= LO_IS_VNODE;
iflags |= flags  (LK_ADAPTIVE | LK_NOSHARE);
 
+   lock_init(lk-lock_object, lock_class_lockmgr, wmesg, NULL, iflags);
lk-lk_lock = LK_UNLOCKED;
lk-lk_recurse = 0;
lk-lk_exslpfail = 0;
lk-lk_timo = timo;
lk-lk_pri = pri;
-   lock_init(lk-lock_object, lock_class_lockmgr, wmesg, NULL, iflags);
STACK_ZERO(lk);
 }
 

Modified: head/sys/kern/kern_mutex.c
==
--- head/sys/kern/kern_mutex.c  Tue Jun 25 20:03:06 2013(r252211)
+++ head/sys/kern/kern_mutex.c  Tue Jun 25 20:23:08 2013(r252212)
@@ -243,7 +243,6 @@ __mtx_unlock_flags(volatile uintptr_t *c
KASSERT(LOCK_CLASS(m-lock_object) == lock_class_mtx_sleep,
(mtx_unlock() of spin mutex %s @ %s:%d, m-lock_object.lo_name,
file, line));
-   curthread-td_locks--;
WITNESS_UNLOCK(m-lock_object, opts | LOP_EXCLUSIVE, file, line);
LOCK_LOG_LOCK(UNLOCK, m-lock_object, opts, m-mtx_recurse, file,
line);
@@ -252,6 +251,7 @@ __mtx_unlock_flags(volatile uintptr_t *c
if (m-mtx_recurse == 0)
LOCKSTAT_PROFILE_RELEASE_LOCK(LS_MTX_UNLOCK_RELEASE, m);
__mtx_unlock(m, curthread, opts, file, line);
+   curthread-td_locks--;
 }
 
 void
@@ -894,10 +894,10 @@ _mtx_init(volatile uintptr_t *c, const c
flags |= LO_NOPROFILE;
 
/* Initialize mutex. */
+   lock_init(m-lock_object, class, name, type, flags);
+
m-mtx_lock = MTX_UNOWNED;
m-mtx_recurse = 0;
-
-   lock_init(m-lock_object, class, name, type, flags);
 }
 
 /*

Modified: head/sys/kern/kern_rwlock.c
==
--- head/sys/kern/kern_rwlock.c Tue Jun 25 20:03:06 2013(r252211)
+++ head/sys/kern/kern_rwlock.c Tue Jun 25 20:23:08 2013(r252212)
@@ -207,9 +207,9 @@ _rw_init_flags(volatile uintptr_t *c, co
if (opts  RW_QUIET)
flags |= LO_QUIET;
 
+   lock_init(rw-lock_object, lock_class_rw, name, NULL, flags);
rw-rw_lock = RW_UNLOCKED;
rw-rw_recurse = 0;
-   lock_init(rw-lock_object, lock_class_rw, name, NULL, flags);
 }
 
 void
@@ -319,13 +319,13 @@ _rw_wunlock_cookie(volatile uintptr_t *c
KASSERT(rw-rw_lock != RW_DESTROYED,
(rw_wunlock() of destroyed rwlock @ %s:%d, file, line));
__rw_assert(c, RA_WLOCKED, file, line);
-   curthread-td_locks--;
WITNESS_UNLOCK(rw-lock_object, LOP_EXCLUSIVE, file, line);
LOCK_LOG_LOCK(WUNLOCK, rw-lock_object, 0, rw-rw_recurse, file,
line);
if (!rw_recursed(rw))
LOCKSTAT_PROFILE_RELEASE_LOCK(LS_RW_WUNLOCK_RELEASE, rw);
__rw_wunlock(rw, curthread, file, line);
+   curthread-td_locks--;
 }
 /*
  * Determines whether a new reader can acquire a lock.  Succeeds if the
@@ -598,8 +598,6 @@ _rw_runlock_cookie(volatile uintptr_t *c
KASSERT(rw-rw_lock != RW_DESTROYED,
(rw_runlock() of destroyed rwlock @ %s:%d, file, line));
__rw_assert(c, RA_RLOCKED, file, line);
-   curthread-td_locks--;
-   curthread-td_rw_rlocks--;
WITNESS_UNLOCK(rw-lock_object, 0, file, line);
LOCK_LOG_LOCK(RUNLOCK, rw-lock_object, 0, 0, file, line);
 
@@ -693,6 +691,8 @@ _rw_runlock_cookie(volatile uintptr_t *c
break;
}

Re: svn commit: r252032 - head/sys/amd64/include

2013-06-25 Thread Konstantin Belousov
On Tue, Jun 25, 2013 at 08:14:41PM +1000, Bruce Evans wrote:
 On Tue, 25 Jun 2013, Konstantin Belousov wrote:
 
  Updates to the counter cannot be done from the interrupt context.
 
 This is fragile, however.  It prevents using counters for things like
 counting interrupts.  Most interrupt counting is now done directlyly
 and doesn't use PCPU_INC().  i386/i386 has just 1 use of PCPU_INC().
 It is to count traps in machdep.c.  Traps include nonmaskable
 interrupts.  Even hard-disabling of interrupts doesn't prevent these.
 Otherwise, PCPU is used mainly for vm counters.  E.g., for pagefaults.
 Now the trap is not an interrupt, so it shouldn't occur in the middle
 of the counter update and the PCPU_INC() can safely be replaced by
 a counter, but this is not clear.
Traps are not performance critical in the sense that there is no need to count
up to 1-10G traps per second.  Anyway, as Gleb said, there is no point in
optimizing the i386 kernel.  

 
  The fetch problem of sometime missing the carry bit is present on all
  32bit arches now, I think.
 
 Also the zeroing problem.  Since there are no atomic ops in sight, zeroing
 has several races.  My transferring code uses atomic ops on only 1 CPU,
 so it has half of these races.  See below.
Right, zeroing should also use atomic 64bit writes on i386.  Updated
patch is at end.

 
  The arm implementation of atomic.h is also relevant and is especially
  interesting.  I looked at it after mdf@ pointed out ARM_RAS_START.
  This seems to only be used by arm in userland.  It is even larger and
  slower and more complicated than critical sections, so it doesn't seem
  to be useful for counters.  In the kernel, arm has several
  implementations depending on machine capabilities.  The ifdefs are
  hard to understand.  On some machine, it seems to use the equivalent
  of a cmpxchg loop.  On others, it just disables interrupts.  Disabling
  interrupts is presumably better than a critical section, and userland
  has to use ARM_RAS_START for some arches because neither disabling
  interrupts not critical sections are available in userland.  None
  of this care helps avoid the races in pcpu.h, since pcpu.h 
  intentionally
  avoids using atomic ops.  None of this care helps avoid the races in
  counter.h or make counter.h efficient, since counter.h uses its own
  methods.  To reach the same quality as atomic.h, counter.h would have
  to copy half of the ifdefs and methods in atomic.h.
  BTW, why do you claim that disabling interrupts is faster and better method
  to disable preemption than critical section ?
 
 For arm, it is because if the critical section method were better, then
 arm should use it for atomic ops too.
Of course not.  Atomics must be atomic WRT the interrupts as well.
Using critical sections only provides atomicity against preemption
but not against interruption.

The arm looks quite deficient anyway.  From the arm/include/atomic.h,
it seems that the arch did not have (usable) atomics until v6.  And
ARM does not support SMP in the stock HEAD still.

 
 For i386, it is because it reduces the window in which the value is invalid
 (other CPUs can see the invalid value), and is easier to use and shorter
 (2-3 bytes) and thus better suited to inline code.  My examples of inline
 code mostly used it in rarely-executed cases where its speed doesn't matter
 and it is just easier to use.  Actual testing shows that it is fairly
 efficient, so can be used in all cases.  On Athlon64, it is faster than
 cmpxchg8b but slower than an inline optimized critical section.  This
 testing is in userland, where there may be an extra penalty for using
 cli/sti/pushfl/popfl:
 
 % static inline void
 % counter_u64_add(counter_u64_t c, int64_t inc)
 % {
 % 
 % #if 1
 % /* 20 cycles on A64. */
 % /* 31 cycles on A64 with lock prefix. */
 % /* 35 cycles on A64 with mfence prefix. */
 % if ((cpu_feature  1) == 1) {
 % counter_64_inc_8b(c, inc);
 % }
 
 Old tests said that this takes 18 cycles.  It now takes 20.
 
 Adding a lock or mfence prefix to the cmpxchg8b gives the times stated
 above.  This shows how bad using cmpxch8b is.  We could use atomic ops
 for everything and only be 50% slower.  But we shouldn't use either
 cmpxchg8b or atomic ops.  We should use 32-bit addl, which takes about
 4 cycles.
Use of cmpxchg8b provides the soundness to the algorithm, by using
atomic 64 bit loads and stores.

As I stated, I am not going to spent time microoptimizing for i386.
Current implementation is good enough.

 
 % struct thread
 % {
 % uint32_t td_critnest;
 % uint32_t td_owepreempt;
 % } td0;
 % 
 % volatile struct thread *td = td0;
 % 
 % void
 % dummy_accum(void)
 % {
 % }
 % 
 % void
 % fake_mi_switch(void)
 % {
 % }
 
 Added more emulation for a complete critical section emulation.
 
 % static inline void
 % alt_counter_u64_add(counter_u64_t c, int64_t inc)
 % {
 % #if 0
 % /* 

svn commit: r252218 - head/cddl/contrib/opensolaris/lib/libzfs/common

2013-06-25 Thread Xin LI
Author: delphij
Date: Tue Jun 25 21:51:52 2013
New Revision: 252218
URL: http://svnweb.freebsd.org/changeset/base/252218

Log:
  Diff reduction against Illumos, no real change to code itself.
  
  This marks vendor branch revision 252213 as merged, the actual code was
  committed in r245479.
  
  MFC after:1 week

Modified:
  head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c
Directory Properties:
  head/cddl/contrib/opensolaris/   (props changed)
  head/cddl/contrib/opensolaris/lib/libzfs/   (props changed)

Modified: head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c
==
--- head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c Tue Jun 
25 21:50:05 2013(r252217)
+++ head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c Tue Jun 
25 21:51:52 2013(r252218)
@@ -22,6 +22,7 @@
 /*
  * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.
  * Copyright (c) 2012 by Delphix. All rights reserved.
+ * Copyright (c) 2013 Steven Hartland. All rights reserved.
  */
 
 /*
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252219 - in head: cddl/contrib/opensolaris/lib/libzfs/common cddl/contrib/opensolaris/lib/libzfs_core/common sys/cddl/contrib/opensolaris/uts/common/fs/zfs

2013-06-25 Thread Xin LI
Author: delphij
Date: Tue Jun 25 22:14:32 2013
New Revision: 252219
URL: http://svnweb.freebsd.org/changeset/base/252219

Log:
  MFV r252215:
  
  Restore a previous behavior before r251646, where when destructing
  ZFS snapshot, the ioctl would return ENOENT when it hit any of
  them in the errlist (the new behavior was only return ENOENT when
  all returns error).
  
  Illumos ZFS issues:
3829 fix for 3740 changed behavior of zfs destroy/hold/release ioctl
  
  MFC after:1 week

Modified:
  head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c
  head/cddl/contrib/opensolaris/lib/libzfs_core/common/libzfs_core.c
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_destroy.c
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_userhold.c
Directory Properties:
  head/cddl/contrib/opensolaris/   (props changed)
  head/cddl/contrib/opensolaris/lib/libzfs/   (props changed)
  head/sys/cddl/contrib/opensolaris/   (props changed)

Modified: head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c
==
--- head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.cTue Jun 
25 21:51:52 2013(r252218)
+++ head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.cTue Jun 
25 22:14:32 2013(r252219)
@@ -21,9 +21,9 @@
 
 /*
  * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.
- * Copyright 2012 Nexenta Systems, Inc. All rights reserved.
- * Copyright (c) 2011 by Delphix. All rights reserved.
+ * Copyright (c) 2013 by Delphix. All rights reserved.
  * Copyright (c) 2012 DEY Storage Systems, Inc.  All rights reserved.
+ * Copyright 2012 Nexenta Systems, Inc. All rights reserved.
  * Copyright (c) 2011-2012 Pawel Jakub Dawidek pa...@dawidek.net.
  * All rights reserved.
  * Copyright (c) 2012 Martin Matuska m...@freebsd.org. All rights reserved.
@@ -4159,6 +4159,7 @@ struct holdarg {
const char *snapname;
const char *tag;
boolean_t recursive;
+   int error;
 };
 
 static int
@@ -4286,15 +4287,20 @@ zfs_release_one(zfs_handle_t *zhp, void 
struct holdarg *ha = arg;
char name[ZFS_MAXNAMELEN];
int rv = 0;
+   nvlist_t *existing_holds;
 
(void) snprintf(name, sizeof (name),
%s@%s, zhp-zfs_name, ha-snapname);
 
-   if (lzc_exists(name)) {
-   nvlist_t *holds = fnvlist_alloc();
-   fnvlist_add_boolean(holds, ha-tag);
-   fnvlist_add_nvlist(ha-nvl, name, holds);
-   fnvlist_free(holds);
+   if (lzc_get_holds(name, existing_holds) != 0) {
+   ha-error = ENOENT;
+   } else if (!nvlist_exists(existing_holds, ha-tag)) {
+   ha-error = ESRCH;
+   } else {
+   nvlist_t *torelease = fnvlist_alloc();
+   fnvlist_add_boolean(torelease, ha-tag);
+   fnvlist_add_nvlist(ha-nvl, name, torelease);
+   fnvlist_free(torelease);
}
 
if (ha-recursive)
@@ -4318,16 +4324,21 @@ zfs_release(zfs_handle_t *zhp, const cha
ha.snapname = snapname;
ha.tag = tag;
ha.recursive = recursive;
+   ha.error = 0;
(void) zfs_release_one(zfs_handle_dup(zhp), ha);
 
if (nvlist_empty(ha.nvl)) {
fnvlist_free(ha.nvl);
-   ret = ENOENT;
+   ret = ha.error;
(void) snprintf(errbuf, sizeof (errbuf),
dgettext(TEXT_DOMAIN,
cannot release hold from snapshot '%s@%s'),
zhp-zfs_name, snapname);
-   (void) zfs_standard_error(hdl, ret, errbuf);
+   if (ret == ESRCH) {
+   (void) zfs_error(hdl, EZFS_REFTAG_RELE, errbuf);
+   } else {
+   (void) zfs_standard_error(hdl, ret, errbuf);
+   }
return (ret);
}
 

Modified: head/cddl/contrib/opensolaris/lib/libzfs_core/common/libzfs_core.c
==
--- head/cddl/contrib/opensolaris/lib/libzfs_core/common/libzfs_core.c  Tue Jun 
25 21:51:52 2013(r252218)
+++ head/cddl/contrib/opensolaris/lib/libzfs_core/common/libzfs_core.c  Tue Jun 
25 22:14:32 2013(r252219)
@@ -302,11 +302,8 @@ lzc_snapshot(nvlist_t *snaps, nvlist_t *
  * marked for deferred destruction, and will be destroyed when the last hold
  * or clone is removed/destroyed.
  *
- * The return value will be ENOENT if none of the snapshots existed.
- *
  * The return value will be 0 if all snapshots were destroyed (or marked for
- * later destruction if 'defer' is set) or didn't exist to begin with and
- * at least one snapshot was destroyed.
+ * later destruction if 'defer' is set) or didn't exist to begin with.
  *
  * Otherwise the return value will be the errno of a (unspecified) snapshot
  * that failed, no snapshots will be destroyed, 

svn commit: r252226 - head/sys/vm

2013-06-25 Thread Jeff Roberson
Author: jeff
Date: Wed Jun 26 00:57:38 2013
New Revision: 252226
URL: http://svnweb.freebsd.org/changeset/base/252226

Log:
   - Resolve bucket recursion issues by passing a cookie with zone flags
 through bucket_alloc() to uma_zalloc_arg() and uma_zfree_arg().
   - Make some smaller buckets for large zones to further reduce memory
 waste.
   - Implement uma_zone_reserve().  This holds aside a number of items only
 for callers who specify M_USE_RESERVE.  buckets will never be filled
 from reserve allocations.
  
  Sponsored by: EMC / Isilon Storage Division

Modified:
  head/sys/vm/uma.h
  head/sys/vm/uma_core.c
  head/sys/vm/uma_int.h

Modified: head/sys/vm/uma.h
==
--- head/sys/vm/uma.h   Wed Jun 26 00:42:45 2013(r252225)
+++ head/sys/vm/uma.h   Wed Jun 26 00:57:38 2013(r252226)
@@ -459,6 +459,12 @@ void uma_reclaim(void);
 void uma_set_align(int align);
 
 /*
+ * Set a reserved number of items to hold for M_USE_RESERVE allocations.  All
+ * other requests must allocate new backing pages.
+ */
+void uma_zone_reserve(uma_zone_t zone, int nitems);
+
+/*
  * Reserves the maximum KVA space required by the zone and configures the zone
  * to use a VM_ALLOC_NOOBJ-based backend allocator.
  *

Modified: head/sys/vm/uma_core.c
==
--- head/sys/vm/uma_core.c  Wed Jun 26 00:42:45 2013(r252225)
+++ head/sys/vm/uma_core.c  Wed Jun 26 00:57:38 2013(r252226)
@@ -206,12 +206,14 @@ struct uma_bucket_zone {
 #defineBUCKET_MAX  BUCKET_SIZE(128)
 
 struct uma_bucket_zone bucket_zones[] = {
+   { NULL, 4 Bucket, BUCKET_SIZE(4), 4096 },
+   { NULL, 8 Bucket, BUCKET_SIZE(8), 2048 },
+   { NULL, 16 Bucket, BUCKET_SIZE(16), 1024 },
{ NULL, 32 Bucket, BUCKET_SIZE(32), 512 },
{ NULL, 64 Bucket, BUCKET_SIZE(64), 256 },
{ NULL, 128 Bucket, BUCKET_SIZE(128), 128 },
{ NULL, NULL, 0}
 };
-static uma_zone_t largebucket;
 
 /*
  * Flags and enumerations to be passed to internal functions.
@@ -246,10 +248,10 @@ static void *zone_alloc_item(uma_zone_t,
 static void zone_free_item(uma_zone_t, void *, void *, enum zfreeskip);
 static void bucket_enable(void);
 static void bucket_init(void);
-static uma_bucket_t bucket_alloc(uma_zone_t zone, int);
-static void bucket_free(uma_zone_t zone, uma_bucket_t);
+static uma_bucket_t bucket_alloc(uma_zone_t zone, void *, int);
+static void bucket_free(uma_zone_t zone, uma_bucket_t, void *);
 static void bucket_zone_drain(void);
-static uma_bucket_t zone_alloc_bucket(uma_zone_t zone, int flags);
+static uma_bucket_t zone_alloc_bucket(uma_zone_t zone, void *, int flags);
 static uma_slab_t zone_fetch_slab(uma_zone_t zone, uma_keg_t last, int flags);
 static uma_slab_t zone_fetch_slab_multi(uma_zone_t zone, uma_keg_t last, int 
flags);
 static void *slab_alloc_item(uma_keg_t keg, uma_slab_t slab);
@@ -304,17 +306,8 @@ bucket_init(void)
size += sizeof(void *) * ubz-ubz_entries;
ubz-ubz_zone = uma_zcreate(ubz-ubz_name, size,
NULL, NULL, NULL, NULL, UMA_ALIGN_PTR,
-   UMA_ZONE_MAXBUCKET | UMA_ZONE_MTXCLASS);
+   UMA_ZONE_MTXCLASS | UMA_ZFLAG_BUCKET);
}
-   /*
-* To avoid recursive bucket allocation loops we disable buckets
-* on the smallest bucket zone and use it for the largest zone.
-* The remainder of the zones all use the largest zone.
-*/
-   ubz--;
-   ubz-ubz_zone-uz_count = bucket_zones[0].ubz_entries;
-   bucket_zones[0].ubz_zone-uz_count = 0;
-   largebucket = ubz-ubz_zone;
 }
 
 /*
@@ -350,7 +343,7 @@ bucket_select(int size)
 }
 
 static uma_bucket_t
-bucket_alloc(uma_zone_t zone, int flags)
+bucket_alloc(uma_zone_t zone, void *udata, int flags)
 {
struct uma_bucket_zone *ubz;
uma_bucket_t bucket;
@@ -363,11 +356,26 @@ bucket_alloc(uma_zone_t zone, int flags)
 */
if (bucketdisable)
return (NULL);
-
-   if (zone-uz_flags  UMA_ZFLAG_CACHEONLY)
+   /*
+* To limit bucket recursion we store the original zone flags
+* in a cookie passed via zalloc_arg/zfree_arg.  This allows the
+* NOVM flag to persist even through deep recursions.  We also
+* store ZFLAG_BUCKET once we have recursed attempting to allocate
+* a bucket for a bucket zone so we do not allow infinite bucket
+* recursion.  This cookie will even persist to frees of unused
+* buckets via the allocation path or bucket allocations in the
+* free path.
+*/
+   if ((uintptr_t)udata  UMA_ZFLAG_BUCKET)
+   return (NULL);
+   if ((zone-uz_flags  UMA_ZFLAG_BUCKET) == 0)
+   udata = (void *)(uintptr_t)zone-uz_flags;
+   else
+   udata = (void *)((uintptr_t)udata | 

svn commit: r252227 - head/sys/dev/bge

2013-06-25 Thread Pyun YongHyeon
Author: yongari
Date: Wed Jun 26 01:15:40 2013
New Revision: 252227
URL: http://svnweb.freebsd.org/changeset/base/252227

Log:
  Don't blidly clear GPIOs configuration. Just use firmware configured
  one.  This change also fixes non-working traffic LED on BCM57780.
  
  Submitted by: Masanobu SAITOH msai...@netbsd.org
  Tested by:Alexander Milanov a...@amilanov.com

Modified:
  head/sys/dev/bge/if_bge.c

Modified: head/sys/dev/bge/if_bge.c
==
--- head/sys/dev/bge/if_bge.c   Wed Jun 26 00:57:38 2013(r252226)
+++ head/sys/dev/bge/if_bge.c   Wed Jun 26 01:15:40 2013(r252227)
@@ -2401,7 +2401,7 @@ bge_blockinit(struct bge_softc *sc)
DELAY(40);
 
/* Set misc. local control, enable interrupts on attentions */
-   CSR_WRITE_4(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_ONATTN);
+   BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_ONATTN);
 
 #ifdef notdef
/* Assert GPIO pins for PHY reset */
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


Re: svn commit: r252032 - head/sys/amd64/include

2013-06-25 Thread Bruce Evans

On Tue, 25 Jun 2013, Konstantin Belousov wrote:


On Tue, Jun 25, 2013 at 08:14:41PM +1000, Bruce Evans wrote:

On Tue, 25 Jun 2013, Konstantin Belousov wrote:


Updates to the counter cannot be done from the interrupt context.


This is fragile, however.  It prevents using counters for things like
counting interrupts.  Most interrupt counting is now done directlyly
and doesn't use PCPU_INC().  i386/i386 has just 1 use of PCPU_INC().
It is to count traps in machdep.c.  Traps include nonmaskable
interrupts.  Even hard-disabling of interrupts doesn't prevent these.
...

Traps are not performance critical in the sense that there is no need to count
up to 1-10G traps per second.


The trap count increment is not a performance problem, but a correctness one.
Disabling interrupts for a multi-word increment doesn't work for NMIs even
for !SMP or pcpu accesses with SMP.


Anyway, as Gleb said, there is no point in
optimizing the i386 kernel.


I said that there is every point in optimizing the i386 kernel.  This
applies even more to other 32-bit arches.  Some CPUs are much slower
than modern x86's.  They shouldn't be slowed down more by inefficient
KPIs.


The fetch problem of sometime missing the carry bit is present on all
32bit arches now, I think.


Also the zeroing problem.  Since there are no atomic ops in sight, zeroing
has several races.  My transferring code uses atomic ops on only 1 CPU,
so it has half of these races.  See below.

Right, zeroing should also use atomic 64bit writes on i386.  Updated
patch is at end.


It's getting even more complicated and further from what I want.  It also
doesn't work.  Disabling interrupts doesn't work for the SMP case.  The
zeroing needs to run in a per-CPU daemon.


The arm implementation of atomic.h is also relevant and is especially
interesting.  I looked at it after mdf@ pointed out ARM_RAS_START.
This seems to only be used by arm in userland.  It is even larger and
slower and more complicated than critical sections, so it doesn't seem
to be useful for counters.  In the kernel, arm has several
implementations depending on machine capabilities.  The ifdefs are
hard to understand.  On some machine, it seems to use the equivalent
of a cmpxchg loop.  On others, it just disables interrupts.  Disabling
interrupts is presumably better than a critical section, and userland
has to use ARM_RAS_START for some arches because neither disabling
interrupts not critical sections are available in userland.  None
of this care helps avoid the races in pcpu.h, since pcpu.h intentionally
avoids using atomic ops.  None of this care helps avoid the races in
counter.h or make counter.h efficient, since counter.h uses its own
methods.  To reach the same quality as atomic.h, counter.h would have
to copy half of the ifdefs and methods in atomic.h.

BTW, why do you claim that disabling interrupts is faster and better method
to disable preemption than critical section ?


For arm, it is because if the critical section method were better, then
arm should use it for atomic ops too.

Of course not.  Atomics must be atomic WRT the interrupts as well.
Using critical sections only provides atomicity against preemption
but not against interruption.


Indeed, atomics would be fragile if they couldn't be used in interrupt
handlers.  So in a non-optimized implementation it is safe to disable
interrupts in hardware.  An optimized solution would accept the fragility
like the counter increment does, and have use special atomic ops that
do more for the few variables that are accessed by interrupt handlers.


The arm looks quite deficient anyway.  From the arm/include/atomic.h,
it seems that the arch did not have (usable) atomics until v6.  And
ARM does not support SMP in the stock HEAD still.


Disabling interrupts only gives atomicity for non-SMP.  Thus the cases
where this method is used indicate an arch that doesn't support SMP.
More interestingly for the current discussion, arm and other several
other arches apparently don't have interrupt-safe load-modify-store
instructions even for register-sized memory variables.  Thus they
need to either disable interrupts or use a cmpxchg-type instruction
even to add to register-sized variables.


% static inline void
% counter_u64_add(counter_u64_t c, int64_t inc)
% {
%
% #if 1
%   /* 20 cycles on A64. */
%   /* 31 cycles on A64 with lock prefix. */
%   /* 35 cycles on A64 with mfence prefix. */
%   if ((cpu_feature  1) == 1) {
%   counter_64_inc_8b(c, inc);
%   }

Old tests said that this takes 18 cycles.  It now takes 20.

Adding a lock or mfence prefix to the cmpxchg8b gives the times stated
above.  This shows how bad using cmpxch8b is.  We could use atomic ops
for everything and only be 50% slower.  But we shouldn't use either
cmpxchg8b or atomic ops.  We should use 32-bit addl, which takes about
4 cycles.

Use of cmpxchg8b provides the soundness to the 

svn commit: r252228 - in head: share/misc usr.bin/calendar/calendars

2013-06-25 Thread Mark Felder
Author: feld (ports committer)
Date: Wed Jun 26 02:21:37 2013
New Revision: 252228
URL: http://svnweb.freebsd.org/changeset/base/252228

Log:
  - Adding myself to the committers-ports.dot
  - Adding myself to the freebsd calendar
  
  Approved by: swills (mentor)

Modified:
  head/share/misc/committers-ports.dot
  head/usr.bin/calendar/calendars/calendar.freebsd

Modified: head/share/misc/committers-ports.dot
==
--- head/share/misc/committers-ports.dotWed Jun 26 01:15:40 2013
(r252227)
+++ head/share/misc/committers-ports.dotWed Jun 26 02:21:37 2013
(r252228)
@@ -90,6 +90,7 @@ ehaupt [label=Emanuel Haupt\nehaupt@Fre
 eik [label=Oliver Eikemeier\n...@freebsd.org\n2003/11/12]
 erwin [label=Erwin Lansing\ner...@freebsd.org\n2003/06/04]
 farrokhi [label=Babak Farrokhi\nfarro...@freebsd.org\n2006/11/07]
+feld [label=Mark Felder\nf...@freebsd.org\n2013/06/25]
 fjoe [label=Max Khon\nf...@freebsd.org\n2001/08/06]
 flo [label=Florian Smeets\n...@freebsd.org\n2010/12/07]
 fluffy [label=Dima Panov\nflu...@freebsd.org\n2009/08/10]
@@ -266,6 +267,7 @@ clement - lawrance
 clsung - lwhsu
 clsung - tabthorpe
 
+crees - feld
 crees - gjb
 crees - jgh
 crees - madpilot
@@ -492,6 +494,7 @@ stas - araujo
 
 steve - netchild
 
+swills - feld
 swills - pclin
 
 tabthorpe - ashish

Modified: head/usr.bin/calendar/calendars/calendar.freebsd
==
--- head/usr.bin/calendar/calendars/calendar.freebsdWed Jun 26 01:15:40 
2013(r252227)
+++ head/usr.bin/calendar/calendars/calendar.freebsdWed Jun 26 02:21:37 
2013(r252228)
@@ -298,6 +298,7 @@
 09/28  Greg Lehey g...@freebsd.org born in Melbourne, Victoria, Australia, 
1948
 09/28  Alex Dupre a...@freebsd.org born in Milano, Italy, 1980
 09/29  Matthew Hunt m...@freebsd.org born in Johnstown, Pennsylvania, United 
States, 1976
+09/30  Mark Felder f...@freebsd.org born in Prairie du Chien, Wisconsin, 
United States, 1985
 09/30  Hiten M. Pandya h...@freebsd.org born in Dar-es-Salaam, Tanzania, 
East Africa, 1986
 09/30  Third quarter status reports are due on 10/15
 10/02  Beat Gaetzi b...@freebsd.org born in Zurich, Switzerland, 1980
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252229 - head/sys/arm/ti

2013-06-25 Thread Rui Paulo
Author: rpaulo
Date: Wed Jun 26 02:56:54 2013
New Revision: 252229
URL: http://svnweb.freebsd.org/changeset/base/252229

Log:
  Print the 'setting internal ...' message only with bootverbose.

Modified:
  head/sys/arm/ti/ti_scm.c

Modified: head/sys/arm/ti/ti_scm.c
==
--- head/sys/arm/ti/ti_scm.cWed Jun 26 02:21:37 2013(r252228)
+++ head/sys/arm/ti/ti_scm.cWed Jun 26 02:56:54 2013(r252229)
@@ -163,7 +163,9 @@ ti_scm_padconf_set_internal(struct ti_sc
/* set the mux mode */
reg_val |= (uint16_t)(mode  ti_scm_dev.padconf_muxmode_mask);

-   printf(setting internal %x for %s\n, reg_val, muxmode);
+   if (bootverbose)
+   device_printf(sc-sc_dev, setting internal %x for %s\n, 
+   reg_val, muxmode);
/* write the register value (16-bit writes) */
ti_scm_write_2(sc, padconf-reg_off, reg_val);

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252230 - in head/etc: . rc.d

2013-06-25 Thread Rui Paulo
Author: rpaulo
Date: Wed Jun 26 04:00:52 2013
New Revision: 252230
URL: http://svnweb.freebsd.org/changeset/base/252230

Log:
  Implement ifconfig_wlanX=HOSTAP.
  
  Not only this is a bit cleaner, it allows multiple instances of hostapd to be
  running on the system host, useful for simultaneous dual-band WiFi.
  This is similar to ifconfig_wlanX=WPA but it uses /etc/hostapd-wlanX.conf.
  Compatibility with hostapd_enable=YES/NO was kept.
  
  Reviewed by:  adrian

Modified:
  head/etc/network.subr
  head/etc/rc.d/hostapd

Modified: head/etc/network.subr
==
--- head/etc/network.subr   Wed Jun 26 02:56:54 2013(r252229)
+++ head/etc/network.subr   Wed Jun 26 04:00:52 2013(r252230)
@@ -171,6 +171,9 @@ ifconfig_up()
if wpaif $1; then
/etc/rc.d/wpa_supplicant start $1
_cfg=0  # XXX: not sure this should count
+   elif hostapif $1; then
+   /etc/rc.d/hostapd start $1
+   _cfg=0
fi
 
if dhcpif $1; then
@@ -198,6 +201,9 @@ ifconfig_down()
if wpaif $1; then
/etc/rc.d/wpa_supplicant stop $1
_cfg=0
+   elif hostapif $1; then
+   /etc/rc.d/hostapd stop $1
+   _cfg=0
fi
 
if dhcpif $1; then
@@ -276,6 +282,7 @@ ifconfig_getargs()
[Nn][Oo][Ss][Yy][Nn][Cc][Dd][Hh][Cc][Pp]) ;;
[Ss][Yy][Nn][Cc][Dd][Hh][Cc][Pp]) ;;
[Ww][Pp][Aa]) ;;
+   [Hh][Oo][Ss][Tt][Aa][Pp]) ;;
*)
_args=$_args $_arg
;;
@@ -376,6 +383,24 @@ wpaif()
return 1
 }
 
+# hostapif if
+#  Returns 0 if the interface is a HOSTAP interface and 1 otherwise.
+hostapif()
+{
+   local _tmpargs _arg
+   _tmpargs=`_ifconfig_getargs $1`
+
+   for _arg in $_tmpargs; do
+   case $_arg in
+   [Hh][Oo][Ss][Tt][Aa][Pp])
+   return 0
+   ;;
+   esac
+   done
+
+   return 1
+}
+
 # afexists af
 #  Returns 0 if the address family is enabled in the kernel
 #  1 otherwise.

Modified: head/etc/rc.d/hostapd
==
--- head/etc/rc.d/hostapd   Wed Jun 26 02:56:54 2013(r252229)
+++ head/etc/rc.d/hostapd   Wed Jun 26 04:00:52 2013(r252230)
@@ -10,11 +10,18 @@
 . /etc/rc.subr
 
 name=hostapd
-rcvar=hostapd_enable
 command=/usr/sbin/${name}
 
-conf_file=/etc/${name}.conf
-pidfile=/var/run/${name}.pid
+ifn=$2
+if [ -z $ifn ]; then
+   rcvar=hostapd_enable
+   conf_file=/etc/${name}.conf
+   pidfile=/var/run/${name}.pid
+else
+   rcvar=
+   conf_file=/etc/${name}-${ifn}.conf
+   pidfile=/var/run/${name}-${ifn}.pid
+fi
 
 command_args=-P ${pidfile} -B ${conf_file}
 required_files=${conf_file}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252231 - head/usr.bin/sed

2013-06-25 Thread Pedro F. Giffuni
Author: pfg
Date: Wed Jun 26 04:14:19 2013
New Revision: 252231
URL: http://svnweb.freebsd.org/changeset/base/252231

Log:
  sed: use getline() instead of fgetln().
  
  In BSD, fgetln() available in libc but in Illumos the Solaris port had to
  include it internally. It also seems to have caused problems [1].
  
  Aid portability by using getline() instead.
  
  Reference:
  https://www.illumos.org/issues/3820 [1]
  
  Submitted by: Johann 'Myrkraverk' Oskarsson joh...@myrkraverk.com
  Reviewed by:  dds
  MFC after:2 weeks

Modified:
  head/usr.bin/sed/main.c

Modified: head/usr.bin/sed/main.c
==
--- head/usr.bin/sed/main.c Wed Jun 26 04:00:52 2013(r252230)
+++ head/usr.bin/sed/main.c Wed Jun 26 04:14:19 2013(r252231)
@@ -1,4 +1,5 @@
 /*-
+ * Copyright (c) 2013 Johann 'Myrkraverk' Oskarsson.
  * Copyright (c) 1992 Diomidis Spinellis.
  * Copyright (c) 1992, 1993
  * The Regents of the University of California.  All rights reserved.
@@ -57,6 +58,7 @@ static const char sccsid[] = @(#)main.c
 #include locale.h
 #include regex.h
 #include stddef.h
+#define _WITH_GETLINE
 #include stdio.h
 #include stdlib.h
 #include string.h
@@ -307,8 +309,9 @@ int
 mf_fgets(SPACE *sp, enum e_spflag spflag)
 {
struct stat sb;
-   size_t len;
-   char *p;
+   ssize_t len;
+   static char *p = NULL;
+   static size_t plen = 0;
int c;
static int firstfile;
 
@@ -424,13 +427,13 @@ mf_fgets(SPACE *sp, enum e_spflag spflag
 * We are here only when infile is open and we still have something
 * to read from it.
 *
-* Use fgetln so that we can handle essentially infinite input data.
-* Can't use the pointer into the stdio buffer as the process space
-* because the ungetc() can cause it to move.
+* Use getline() so that we can handle essentially infinite input
+* data.  The p and plen are static so each invocation gives
+* getline() the same buffer which is expanded as needed.
 */
-   p = fgetln(infile, len);
-   if (ferror(infile))
-   errx(1, %s: %s, fname, strerror(errno ? errno : EIO));
+   len = getline(p, plen, infile);
+   if (len == -1)
+   err(1, %s, fname);
if (len != 0  p[len - 1] == '\n')
len--;
cspace(sp, p, len, spflag);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252232 - head/share/man/man5

2013-06-25 Thread Rui Paulo
Author: rpaulo
Date: Wed Jun 26 04:33:32 2013
New Revision: 252232
URL: http://svnweb.freebsd.org/changeset/base/252232

Log:
  Document ifconfig_wlanX=HOSTAP

Modified:
  head/share/man/man5/rc.conf.5

Modified: head/share/man/man5/rc.conf.5
==
--- head/share/man/man5/rc.conf.5   Wed Jun 26 04:14:19 2013
(r252231)
+++ head/share/man/man5/rc.conf.5   Wed Jun 26 04:33:32 2013
(r252232)
@@ -24,7 +24,7 @@
 .\
 .\ $FreeBSD$
 .\
-.Dd June 20, 2013
+.Dd June 25, 2013
 .Dt RC.CONF 5
 .Os
 .Sh NAME
@@ -1321,7 +1321,7 @@ it is possible to use something like:
 ifconfig_ed0=DHCP
 .Ed
 .Pp
-Also, if you want to configure your wireless interface with
+If you want to configure your wireless interface with
 .Xr wpa_supplicant 8
 for use with WPA, EAP/LEAP or WEP, you need to add
 .Dq Li WPA
@@ -1329,6 +1329,17 @@ to the
 .Va ifconfig_ Ns Aq Ar interface
 variable.
 .Pp
+On the other hand, if you want to configure your wireless interface with
+.Xr hostapd 8 ,
+you need to add
+.Dq Li HOSTAP
+to the
+.Va ifconfig_ Ns Aq Ar interface
+variable.
+.Xr hostapd 8
+will use the settings from
+.Pa /etc/hostapd- Ns Ao Ar interface Ac Ns .conf
+.Pp
 Finally, you can add
 .Xr ifconfig 8
 options in this variable, in addition to the
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252233 - head/sys/contrib/dev/ath/ath_hal/ar9300

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 04:33:57 2013
New Revision: 252233
URL: http://svnweb.freebsd.org/changeset/base/252233

Log:
  Add a stub AR93xx RF module just to keep the linker happy.
  
  When building AR933x test images, I'd like to only build only the ar9300
  HAL.  To do this, it needs to supply an RF linker entry or it won't compile.
  
  Tested:
  
  * AR933x test builds

Modified:
  head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.c

Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.c
==
--- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.cWed Jun 26 
04:33:32 2013(r252232)
+++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd.cWed Jun 26 
04:33:57 2013(r252233)
@@ -652,3 +652,24 @@ ar9300SetMulticastFilterIndex(struct ath
}
return (AH_TRUE);
 }
+
+/*
+ * RF attach stubs
+ */
+
+static HAL_BOOL
+rf9330_attach(struct ath_hal *ah, HAL_STATUS *status)
+{
+
+   (*status) = HAL_EINVAL;
+   return (AH_FALSE);
+}
+
+static HAL_BOOL
+rf9330_probe(struct ath_hal *ah)
+{
+   return (AH_FALSE);
+}
+
+AH_RF(RF9330, rf9330_probe, rf9330_attach);
+
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252235 - head/sys/contrib/dev/ath/ath_hal/ar9300

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 04:34:45 2013
New Revision: 252235
URL: http://svnweb.freebsd.org/changeset/base/252235

Log:
  In preparation to support AR933x SoC builds, allow the AH_SUPPORT_AR93(xx)
  options to set the AR9300 HAL defines.
  
  This enables the Wasp, Hornet (and later Scorpion) SoC code.

Modified:
  head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd_inc.h

Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd_inc.h
==
--- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd_inc.hWed Jun 
26 04:34:16 2013(r252234)
+++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_freebsd_inc.hWed Jun 
26 04:34:45 2013(r252235)
@@ -51,10 +51,13 @@
 #defineAH_SUPPORT_AR9300   1
 
 /* These are the embedded boards; we don't currently support these */
-//#define AH_SUPPORT_HORNET   1
-//#define AH_SUPPORT_WASP 1
+#ifdef AH_SUPPORT_AR9330
+#define AH_SUPPORT_HORNET  1
+#endif /* AH_SUPPORT_AR9330 */
+#ifdef AH_SUPPORT_AR9340
+#define AH_SUPPORT_WASP1
+#endif /* AH_SUPPORT_AR9340 */
 //#define AH_SUPPORT_SCORPION 1
-
 #define FIX_NOISE_FLOOR 1
 
 /* XXX this needs to be removed! No atomics in the HAL! */
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252236 - head/sys/dev/ath/ath_hal

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 04:46:03 2013
New Revision: 252236
URL: http://svnweb.freebsd.org/changeset/base/252236

Log:
  Add a HAL local routine to map the 2GHz channel frequency to an IEEE
  channel.
  
  There's some HAL code in the AR9300 HAL that requires a back-mapping
  and using the net80211 code isn't appropriate here.

Modified:
  head/sys/dev/ath/ath_hal/ah.c
  head/sys/dev/ath/ath_hal/ah_internal.h

Modified: head/sys/dev/ath/ath_hal/ah.c
==
--- head/sys/dev/ath/ath_hal/ah.c   Wed Jun 26 04:34:45 2013
(r252235)
+++ head/sys/dev/ath/ath_hal/ah.c   Wed Jun 26 04:46:03 2013
(r252236)
@@ -1409,3 +1409,21 @@ ath_hal_EepromDataRead(struct ath_hal *a
(*data) = ah-ah_eepromdata[off];
return AH_TRUE;
 }
+
+/*
+ * Do a 2GHz specific MHz-IEEE based on the hardware
+ * frequency.
+ *
+ * This is the unmapped frequency which is programmed into the hardware.
+ */
+int
+ath_hal_mhz2ieee_2ghz(struct ath_hal *ah, HAL_CHANNEL_INTERNAL *ichan)
+{
+
+   if (ichan-channel == 2484)
+   return 14;
+   if (ichan-channel  2484)
+   return ((int) ichan-channel - 2407) / 5;
+   else
+   return 15 + ((ichan-channel - 2512) / 20);
+}

Modified: head/sys/dev/ath/ath_hal/ah_internal.h
==
--- head/sys/dev/ath/ath_hal/ah_internal.h  Wed Jun 26 04:34:45 2013
(r252235)
+++ head/sys/dev/ath/ath_hal/ah_internal.h  Wed Jun 26 04:46:03 2013
(r252236)
@@ -1021,5 +1021,9 @@ ath_hal_getantennaallowed(struct ath_hal
return (chan-ic_maxantgain);
 }
 
+/*
+ * Map the given 2GHz channel to an IEEE number.
+ */
+extern int ath_hal_mhz2ieee_2ghz(struct ath_hal *, HAL_CHANNEL_INTERNAL *);
 
 #endif /* _ATH_AH_INTERAL_H_ */
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252237 - head/sys/contrib/dev/ath/ath_hal/ar9300

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 04:46:43 2013
New Revision: 252237
URL: http://svnweb.freebsd.org/changeset/base/252237

Log:
  Re-enable the channel set code for the AR933x.
  
  This required a HAL change to map the 2GHz frequency back to an IEEE
  channel number in order to fetch some value(s) to program in.

Modified:
  head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_radio.c

Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_radio.c
==
--- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_radio.c  Wed Jun 26 
04:46:03 2013(r252236)
+++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_radio.c  Wed Jun 26 
04:46:43 2013(r252237)
@@ -86,9 +86,7 @@ ar9300_set_channel(struct ath_hal *ah, s
 u_int8_t clk_25mhz = AH9300(ah)-clk_25mhz;
 CHAN_CENTERS centers;
 int load_synth_channel;
-#ifdef AH_DEBUG_ALQ
 HAL_CHANNEL_INTERNAL *ichan = ath_hal_checkchannel(ah, chan);
-#endif
 
 /*
  * Put this behind AH_DEBUG_ALQ for now until the Hornet
@@ -106,12 +104,6 @@ ar9300_set_channel(struct ath_hal *ah, s
 b_mode = 1; /* 2 GHz */
 
 if (AR_SREV_HORNET(ah)) {
-/*
- * XXX TODO: this should call ieee80211_mhz2ieee which will
- * take care of the up/down conversion and GSM mapping.
- * However, the HAL _can't_ call that, so we'll need to
- * introduce it in ah_osdep or something.
- */
 #if 0
 u_int32_t ichan =
   ieee80211_mhz2ieee(ah, chan-ic_freq, chan-ic_flags);
@@ -121,10 +113,16 @@ ar9300_set_channel(struct ath_hal *ah, s
 } else {
 channel_sel = ar9300_chansel_xtal_40M[ichan - 1];
 }
-#else
-ath_hal_printf(ah, %s: unimplemented, implement!\n, __func__);
-return AH_FALSE;
 #endif
+uint32_t i;
+
+i = ath_hal_mhz2ieee_2ghz(ah, ichan);
+HALASSERT(i  0  i = 14);
+if (clk_25mhz) {
+channel_sel = ar9300_chansel_xtal_25M[i - 1];
+} else {
+channel_sel = ar9300_chansel_xtal_40M[i - 1];
+}
 } else if (AR_SREV_POSEIDON(ah) || AR_SREV_APHRODITE(ah)) {
 u_int32_t channel_frac;
 /* 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252238 - head/sys/contrib/dev/ath/ath_hal/ar9300

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 04:53:33 2013
New Revision: 252238
URL: http://svnweb.freebsd.org/changeset/base/252238

Log:
  If EEPROM data is provided by the AHB layer, copy it in.
  
  This is required for the flash layer code to correctly work.
  
  Tested:
  
  * AR9330 SoC (carambola 2)

Modified:
  head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_attach.c

Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_attach.c
==
--- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_attach.c Wed Jun 26 
04:46:43 2013(r252237)
+++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_attach.c Wed Jun 26 
04:53:33 2013(r252238)
@@ -640,6 +640,12 @@ ar9300_attach(u_int16_t devid, HAL_SOFTC
 /* FreeBSD: to make OTP work for now, provide this.. */
 AH9300(ah)-ah_cal_mem = ath_hal_malloc(HOST_CALDATA_SIZE);
 
+/*
+ * If eepromdata is not NULL, copy it it into ah_cal_mem.
+ */
+if (eepromdata != NULL)
+OS_MEMCPY(AH9300(ah)-ah_cal_mem, eepromdata, HOST_CALDATA_SIZE);
+
 /* XXX FreeBSD: enable RX mitigation */
 ah-ah_config.ath_hal_intr_mitigation_rx = 1;
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252239 - head/sys/dev/ath

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 04:58:25 2013
New Revision: 252239
URL: http://svnweb.freebsd.org/changeset/base/252239

Log:
  Extend the AHB code to work on chips besides the AR9130.
  
  The AHB code:
  
  * hard coded the AR9130 device id;
  * assumes a 4k flash calibration space.
  
  This code now extends this:
  
  * hint.ath.X.eepromsize now overrides the eeprom range, instead of 4k
  * hint.ath.X.device_id and hint.ath.X.vendor_id can now be overridden.
  
  Tested:
  
  * AR9330 board (Carambola 2)

Modified:
  head/sys/dev/ath/if_ath_ahb.c

Modified: head/sys/dev/ath/if_ath_ahb.c
==
--- head/sys/dev/ath/if_ath_ahb.c   Wed Jun 26 04:53:33 2013
(r252238)
+++ head/sys/dev/ath/if_ath_ahb.c   Wed Jun 26 04:58:25 2013
(r252239)
@@ -85,10 +85,28 @@ struct ath_ahb_softc {
 static int
 ath_ahb_probe(device_t dev)
 {
+   int vendor_id, device_id;
const char* devname;
 
-   /* Atheros / ar9130 */
-   devname = ath_hal_probe(VENDOR_ATHEROS, AR9130_DEVID);
+   /*
+* Check if a device/vendor ID is provided in hints.
+*/
+   if (resource_int_value(device_get_name(dev), device_get_unit(dev),
+   vendor_id, vendor_id) != 0) {
+   vendor_id = VENDOR_ATHEROS;
+   }
+
+   if (resource_int_value(device_get_name(dev), device_get_unit(dev),
+   device_id, device_id) != 0) {
+   device_id = AR9130_DEVID;
+   }
+
+   device_printf(dev, Vendor=0x%04x, Device=0x%04x\n,
+   vendor_id  0x,
+   device_id  0x);
+
+   /* Attempt to probe */
+   devname = ath_hal_probe(vendor_id, device_id);
 
if (devname != NULL) {
device_set_desc(dev, devname);
@@ -105,7 +123,9 @@ ath_ahb_attach(device_t dev)
int error = ENXIO;
int rid;
long eepromaddr;
+   int eepromsize;
uint8_t *p;
+   int device_id, vendor_id;
 
sc-sc_dev = dev;
 
@@ -116,15 +136,27 @@ ath_ahb_attach(device_t dev)
goto bad;
}
 
-if (resource_long_value(device_get_name(dev), device_get_unit(dev),
-eepromaddr, eepromaddr) != 0) {
+   if (resource_long_value(device_get_name(dev), device_get_unit(dev),
+   eepromaddr, eepromaddr) != 0) {
device_printf(dev, cannot fetch 'eepromaddr' from hints\n);
goto bad0;
-}
+   }
+
+   /*
+* The default EEPROM size is 2048 * 16 bit words.
+* Later EEPROM/OTP/flash regions may be quite a bit bigger.
+*/
+   if (resource_int_value(device_get_name(dev), device_get_unit(dev),
+   eepromsize, eepromsize) != 0) {
+   eepromsize = ATH_EEPROM_DATA_SIZE * 2;
+   }
+
+
rid = 0;
-   device_printf(sc-sc_dev, eeprom @ %p\n, (void *) eepromaddr);
+   device_printf(sc-sc_dev, eeprom @ %p (%d bytes)\n,
+   (void *) eepromaddr, eepromsize);
psc-sc_eeprom = bus_alloc_resource(dev, SYS_RES_MEMORY, rid, 
(uintptr_t) eepromaddr,
- (uintptr_t) eepromaddr + (uintptr_t) ((ATH_EEPROM_DATA_SIZE * 2) - 
1), 0, RF_ACTIVE);
+ (uintptr_t) eepromaddr + (uintptr_t) (eepromsize - 1), 0, RF_ACTIVE);
if (psc-sc_eeprom == NULL) {
device_printf(dev, cannot map eeprom space\n);
goto bad0;
@@ -140,7 +172,7 @@ ath_ahb_attach(device_t dev)
sc-sc_invalid = 1;
 
/* Copy the EEPROM data out */
-   sc-sc_eepromdata = malloc(ATH_EEPROM_DATA_SIZE * 2, M_TEMP, M_NOWAIT | 
M_ZERO);
+   sc-sc_eepromdata = malloc(eepromsize, M_TEMP, M_NOWAIT | M_ZERO);
if (sc-sc_eepromdata == NULL) {
device_printf(dev, cannot allocate memory for eeprom data\n);
goto bad1;
@@ -151,10 +183,10 @@ ath_ahb_attach(device_t dev)
bus_space_read_multi_1(
rman_get_bustag(psc-sc_eeprom),
rman_get_bushandle(psc-sc_eeprom),
-   0, (u_int8_t *) sc-sc_eepromdata, ATH_EEPROM_DATA_SIZE * 2);
+   0, (u_int8_t *) sc-sc_eepromdata, eepromsize);
 #endif
p = (void *) rman_get_bushandle(psc-sc_eeprom);
-   memcpy(sc-sc_eepromdata, p, ATH_EEPROM_DATA_SIZE * 2);
+   memcpy(sc-sc_eepromdata, p, eepromsize);
 
/*
 * Arrange interrupt line.
@@ -191,6 +223,19 @@ ath_ahb_attach(device_t dev)
goto bad3;
}
 
+   /*
+* Check if a device/vendor ID is provided in hints.
+*/
+   if (resource_int_value(device_get_name(dev), device_get_unit(dev),
+   vendor_id, vendor_id) != 0) {
+   vendor_id = VENDOR_ATHEROS;
+   }
+
+   if (resource_int_value(device_get_name(dev), device_get_unit(dev),
+   device_id, device_id) != 0) {
+   device_id = AR9130_DEVID;
+   }
+
ATH_LOCK_INIT(sc);
ATH_PCU_LOCK_INIT(sc);
ATH_RX_LOCK_INIT(sc);
@@ -198,7 +243,7 @@ 

svn commit: r252240 - head/sys/conf

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 05:01:50 2013
New Revision: 252240
URL: http://svnweb.freebsd.org/changeset/base/252240

Log:
  Add in two new configuration options for the current generation SoCs.

Modified:
  head/sys/conf/options

Modified: head/sys/conf/options
==
--- head/sys/conf/options   Wed Jun 26 04:58:25 2013(r252239)
+++ head/sys/conf/options   Wed Jun 26 05:01:50 2013(r252240)
@@ -785,6 +785,10 @@ AH_SUPPORT_AR5416  opt_ah.h
 # XXX when actually targetting AR9130.
 AH_SUPPORT_AR9130  opt_ah.h
 
+# This is required for AR933x SoC support
+AH_SUPPORT_AR9330  opt_ah.h
+AH_SUPPORT_AR9340  opt_ah.h
+
 AH_DEBUG   opt_ah.h
 AH_ASSERT  opt_ah.h
 AH_DEBUG_ALQ   opt_ah.h
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252242 - head/sys/mips/conf

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 05:02:47 2013
New Revision: 252242
URL: http://svnweb.freebsd.org/changeset/base/252242

Log:
  Add in the vendor / device id so the ath_ahb glue works.

Modified:
  head/sys/mips/conf/AR933X_BASE.hints

Modified: head/sys/mips/conf/AR933X_BASE.hints
==
--- head/sys/mips/conf/AR933X_BASE.hintsWed Jun 26 05:02:30 2013
(r252241)
+++ head/sys/mips/conf/AR933X_BASE.hintsWed Jun 26 05:02:47 2013
(r252242)
@@ -37,6 +37,8 @@ hint.ath.0.at=nexus0
 hint.ath.0.maddr=0x1810
 hint.ath.0.msize=0x2
 hint.ath.0.irq=0
+hint.ath.0.vendor_id=0x168c
+hint.ath.0.device_id=0x0035
 # Set this to define where the ath calibration data
 # should be fetched from in physical memory.
 # hint.ath.0.eepromaddr=0x1fff1000
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252241 - head/sys/mips/conf

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 05:02:30 2013
New Revision: 252241
URL: http://svnweb.freebsd.org/changeset/base/252241

Log:
  Add the wireless support to the AR933x base kernel, as the support
  actually works now.

Modified:
  head/sys/mips/conf/AR933X_BASE

Modified: head/sys/mips/conf/AR933X_BASE
==
--- head/sys/mips/conf/AR933X_BASE  Wed Jun 26 05:01:50 2013
(r252240)
+++ head/sys/mips/conf/AR933X_BASE  Wed Jun 26 05:02:30 2013
(r252241)
@@ -70,26 +70,27 @@ options IEEE80211_SUPPORT_MESH
 optionsIEEE80211_SUPPORT_TDMA
 optionsIEEE80211_SUPPORT_SUPERG
 optionsIEEE80211_ALQ   # 802.11 ALQ logging support
-#devicewlan# 802.11 support
-#devicewlan_wep# 802.11 WEP support
-#devicewlan_ccmp   # 802.11 CCMP support
-#devicewlan_tkip   # 802.11 TKIP support
-#devicewlan_xauth  # 802.11 hostap support
+device wlan# 802.11 support
+device wlan_wep# 802.11 WEP support
+device wlan_ccmp   # 802.11 CCMP support
+device wlan_tkip   # 802.11 TKIP support
+device wlan_xauth  # 802.11 hostap support
 
 # ath(4)
-#deviceath # Atheros network device
-#deviceath_rate_sample
-#deviceath_ahb # Atheros host bus glue
+device ath # Atheros network device
+device ath_rate_sample
+device ath_ahb # Atheros host bus glue
 optionsATH_DEBUG
 optionsATH_DIAGAPI
 option ATH_ENABLE_11N
 option AH_DEBUG_ALQ
 
-# device   ath_hal
-optionsAH_DEBUG
-option AH_SUPPORT_AR5416
-option AH_SUPPORT_AR9130   # Makes other chipsets not function!
-option AH_DEBUG_ALQ
+#deviceath_hal
+device ath_ar9300  # AR9330 HAL; no need for the others
+option AH_DEBUG
+option AH_SUPPORT_AR5416   # 11n HAL support
+option AH_SUPPORT_AR9330   # Chipset support
+option AH_DEBUG_ALQ
 option AH_AR5416_INTERRUPT_MITIGATION
 
 device mii
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org


svn commit: r252243 - head/sys/mips/conf

2013-06-25 Thread Adrian Chadd
Author: adrian
Date: Wed Jun 26 05:03:47 2013
New Revision: 252243
URL: http://svnweb.freebsd.org/changeset/base/252243

Log:
  Add the EEPROM start offset and size in so ath_ahb will use the
  supplied EEPROM data.
  
  This needs to die in a fire and replaced with the firmware API
  to store the calibration data early ..

Modified:
  head/sys/mips/conf/CARAMBOLA2.hints

Modified: head/sys/mips/conf/CARAMBOLA2.hints
==
--- head/sys/mips/conf/CARAMBOLA2.hints Wed Jun 26 05:02:47 2013
(r252242)
+++ head/sys/mips/conf/CARAMBOLA2.hints Wed Jun 26 05:03:47 2013
(r252243)
@@ -29,6 +29,11 @@ hint.arge.1.phymask=0x0  # No directly m
 hint.arge.1.media=1000
 hint.arge.1.fduplex=1
 
+# Where the ART is - last 64k in the flash
+# 0x9fff1000 ?
+hint.ath.0.eepromaddr=0x1fff
+hint.ath.0.eepromsize=16384
+
 # The AP121 16MB flash layout:
 #
 # [0.70] 0x-0x0004 : u-boot
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org