summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Install filemon.h into /usr/include for userland consumption.obrien2012-06-202-1/+3
|
* Check proper flag (PDF_DAEMON, not PD_DAEMON) when deciding if the processpjd2012-06-191-2/+2
| | | | | | | | | | should be killed or not. This fixes killing pdfork(2)ed process on last close of the corresponding process descriptor. Reviewed by: rwatson MFC after: 1 month
* The falloc() function obtains two references to newly created 'fp'.pjd2012-06-191-2/+6
| | | | | | | | | | | | On success we have to drop one after procdesc_finit() and on failure we have to close allocated slot with fdclose(), which also drops one reference for us and drop the remaining reference with fdrop(). Without this change closing process descriptor didn't result in killing pdfork(2)ed child. Reviewed by: rwatson MFC after: 1 month
* Further refine the implementation of POSIX_FADV_NOREUSE.jhb2012-06-194-16/+94
| | | | | | | | | | | | | | | | | | | | | | | | First, extend the changes in r230782 to better handle the common case of using NOREUSE with sequential reads. A NOREUSE file descriptor will now track the last implicit DONTNEED request it made as a result of a NOREUSE read. If a subsequent NOREUSE read is adjacent to the previous range, it will apply the DONTNEED request to the entire range of both the previous read and the current read. The effect is that each read of a file accessed sequentially will apply the DONTNEED request to the entire range that has been read. This allows NOREUSE to properly handle misaligned reads by flushing each buffer to cache once it has been completely read. Second, apply the same changes made to read(2) by r230782 and this change to writes. This provides much better performance in the sequential write case as it allows writes to still be clustered. It also provides much better performance for misaligned writes. It does mean that NOREUSE will be generally ineffective for non-sequential writes as the current implementation relies on a future NOREUSE write's implicit DONTNEED request to flush the dirty buffer from the current write. MFC after: 2 weeks
* Correct misunderstanding of hw.est.strictsbruno2012-06-191-2/+2
| | | | | | | | | | | | | Setting strict causes a validation of the requested value vs the value currently running after a frequency change is requested. Change applicability to be single core not i386. Thanks to mav@ for reviewing and commenting on my lack of understanding. MFC after: 2 weeks
* Add a 'wmask' variable to hold the expression '(1ul << w->step) - 1' injhb2012-06-191-9/+8
| | | | | | | pcib_grow_window(). This makes the code slightly easier to read and prevents the type of bug fixed in r237271. MFC after: 3 days
* Fix another off-by-one error in the previous fix so that the new startjhb2012-06-191-2/+2
| | | | | address is properly aligned. While here, use a simpler expression to align the new end address that we use elsewhere for aligning the end.
* Passive mode is the default, and has been for a while.des2012-06-191-1/+1
| | | | MFC after: 1 week
* Switch the default password hash from md5 to sha512.des2012-06-192-2/+2
| | | | MFC after: 1 week
* Revert user comparison back to user names as some user can share uids (root/toorbapt2012-06-191-6/+13
| | | | | | | | | | | for example) get the username information from old_pw structures to still allow renaming of a user. Reported by: Claude Buisson <clbuisson@orange.fr> Approved by: des (mentor) MFC after: 3 weeks
* Condition the implementation of pv_entry_count on PV_STATS. On amd64,alc2012-06-191-16/+16
| | | | | | | pv_entry_count is purely informational. It does not serve any functional purpose. Add PV chunk locking to get_pv_entry().
* - Updated TOE support in the kernel.np2012-06-19104-12860/+10887
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Stateful TCP offload drivers for Terminator 3 and 4 (T3 and T4) ASICs. These are available as t3_tom and t4_tom modules that augment cxgb(4) and cxgbe(4) respectively. The cxgb/cxgbe drivers continue to work as usual with or without these extra features. - iWARP driver for Terminator 3 ASIC (kernel verbs). T4 iWARP in the works and will follow soon. Build-tested with make universe. 30s overview ============ What interfaces support TCP offload? Look for TOE4 and/or TOE6 in the capabilities of an interface: # ifconfig -m | grep TOE Enable/disable TCP offload on an interface (just like any other ifnet capability): # ifconfig cxgbe0 toe # ifconfig cxgbe0 -toe Which connections are offloaded? Look for toe4 and/or toe6 in the output of netstat and sockstat: # netstat -np tcp | grep toe # sockstat -46c | grep toe Reviewed by: bz, gnn Sponsored by: Chelsio communications. MFC after: ~3 months (after 9.1, and after ensuring MFC is feasible)
* Add __unused macros to appropriate places in order to allow buildingeadler2012-06-196-15/+14
| | | | | | | with WARNS=6 on base gcc, gcc46, and clang Approved by: cperciva MFC after: 1 week
* Allow users with RO privilege to the device to read the RO attributes.eadler2012-06-1910-35/+41
| | | | | | | | PR: bin/167302 Submitted by: markham breitbach <markham@ssimicro.com> Discussed with: pjd (briefly) Approved by: cperciva MFC after: 1 week
* Remove variables which are initialized but never used thereafter reported by ↵eadler2012-06-191-3/+1
| | | | | | | gcc46 warning Approved by: cperciva MFC After: 3 days
* Remove variables which are initialized but never used thereafter reported by ↵eadler2012-06-191-3/+0
| | | | | | | gcc46 warning Approved by: cperciva MFC After: 3 days
* Remove variables which are initialized but never used thereafter reported by ↵eadler2012-06-191-3/+2
| | | | | | | gcc46 warning Approved by: cperciva MFC After: 3 days
* Remove variables which are initialized but never used thereafter reported by ↵eadler2012-06-191-6/+2
| | | | | | | gcc46 warning Approved by: cperciva MFC After: 3 days
* Remove variables which are initialized but never used thereafter reported by ↵eadler2012-06-191-2/+1
| | | | | | | gcc46 warning Approved by: cperciva MFC After: 3 days
* Remove variables which are initialized but never used thereafter reported by ↵eadler2012-06-192-8/+1
| | | | | | | gcc46 warning Approved by: cperciva MFC After: 3 days
* Remove end of line whitespace.joel2012-06-191-2/+2
|
* Minor mdoc fixes.joel2012-06-191-6/+4
|
* Document support for Intel Enhanced Speedstep Tech interfacesbruno2012-06-182-0/+101
| | | | | | | | | | | | | of cpufreq(4) via a new man page est(4) Document the two exposed tuneables of est(4). I'd appreciate more reviews of content if possible. I gleaned the information contained herein from sys/x86/cpufreq/est.c and the Intel reference documentation Reviewed by: wblock hrs gjb MFC after: 2 weeks
* Fix the NFSv4 client for the case where mmap'd files arermacklem2012-06-181-5/+15
| | | | | | | | | | | | | | | | written, but not msync'd by a process. A VOP_PUTPAGES() called when VOP_RECLAIM() happens will usually fail, since the NFSv4 Open has already been closed by VOP_INACTIVE(). Add a vm_object_page_clean() call to the NFSv4 client's VOP_INACTIVE(), so that the write happens before the NFSv4 Open is closed. kib@ suggested using vgone() instead and I will explore this, but this patch fixes things in the meantime. For some reason, the VOP_PUTPAGES() is still attaempted in VOP_RECLAIM(), but having this fail doesn't cause any problems except a "stateid0 in write" being logged. Reviewed by: kib MFC after: 1 week
* Adjust the fix in r236953, by not generating the signal manually, butkib2012-06-181-11/+5
| | | | | | | | | performing the return to usermode using full return path. This consolidates the handling of exceptional situations in less number of places, and is less code as well. Reviewed by: jhb MFC after: 1 week
* Revert r236529, re-enabling verification of the flashed content asmarius2012-06-181-2/+0
| | | | | the underlying problem was dealt with in r237239 (in fact, disabling verification also actually only made the problem less likely to occur).
* Revert the part of r236495 that introduced checking of SPI_SR_TXEMPTYmarius2012-06-181-14/+8
| | | | | | | | | | | | for TX transfer completion as for reasons unknown this occasionally causes SPI_SR_RXBUFF and SPI_SR_ENDRX to not rise. In any case, once the RX part of the transfer is done it's obvious that the preceding TX part had finished and checking of SPI_SR_TXEMPTY was introduced to rule out a possible cause for the data corruption mentioned in r236495 but which didn't turn out to be the problem anyway. MFC after: 3 days
* Try to bring this file closer to style(9).marius2012-06-181-26/+42
|
* Unbreak after r236658 by comparing the right things.marius2012-06-181-2/+2
|
* Refine r237102 a bit:marius2012-06-182-4/+16
| | | | | | | - Anounce JTAG interfaces deliberately skipped. - Bring back empty lines too eagerly removed. MFC after: 3 days
* Document the hw.ahci.force tunable here, too, as it's also used bymarius2012-06-181-2/+6
| | | | | | ataahci(4) and atanvidia(4). MFC after: 3 days
* Avoid hard sentence break.marius2012-06-181-2/+3
| | | | MFC after: 3 days
* Add rate limitation for SCTP OOTB responses.tuexen2012-06-183-10/+5
| | | | MFC after: 3 days
* Cleanup the UDP decapsulation code.tuexen2012-06-181-42/+20
| | | | MFC after: 3 days
* Add PV chunk and list locking to pmap_page_exists_quick(),alc2012-06-181-15/+63
| | | | | pmap_page_is_mapped(), and pmap_remove_pages(). These functions are no longer serialized by the pvh global lock.
* Make radix lookup on src and dst flow addresses optionalmelifaro2012-06-184-101/+151
| | | | | | | | | | | | | and configurable on per-interface basis. Remove __inline__ for several functions being called once per flow (e.g once per 10-20 packets on common traffic flows). Update manual page to simplify search for BPF data link types. Sponsored by Yandex LLC Reviewed by: glebius Approved by: ae(mentor) MFC after: 2 weeks
* Simplify IP pointer recovery in case of mbuf reallocation.melifaro2012-06-181-53/+15
| | | | | | Reviewed by: glebius (previous version) Approved by: ae(mentor) MFC after: 2 weeks
* Remove never used CD/DA_FLAG_TAGGED_QUEUING flags.mav2012-06-182-6/+0
| | | | MFC after: 1 week
* Fix the previous commit to only copy the data we were asked to and notphk2012-06-181-0/+1
| | | | | | twice as much. Spotted by: Taku YAMAMOTO
* In tty_makedev() the following construction:pho2012-06-181-2/+19
| | | | | | | | | | | | | | dev = make_dev_cred(); dev->si_drv1 = tp; leaves a small window where the newly created device may be opened and si_drv1 is NULL. As this is a vary rare situation, using a lock to close the window seems overkill. Instead just wait for the assignment of si_drv1. Suggested by: kib MFC after: 1 week
* Extend the radiotap code to be aware of the size of any extra vendoradrian2012-06-182-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmaps that may occur. The way this works is: * the beginning of the radiotap frame has a 32 bit "radiotap" namespace bitmap; * if the vendor bitmap bit is set, then the next bitmap will be interpreted as a vendor bitmap; * this can keep going on and on (ie, more vendor and radiotap namespace bitmaps can be added) until the last bitmap with no "more bitmaps" set. Now, the radiotap code gets its grubby fingers into the supplied radiotap rx/tx buffer and replaces the channel configuration for each frame. I don't know why it's not up to the drivers themselves to do this, but I digress. So, if a vendor bitmap (or two, etc) exists, the offset calculations will be all completely wrong. This particular patch introduces ieee80211_radiotap_attachv(), which includes the number of vendor bitmaps (well, any other bitmaps, vendor or otherwise) between the end of the bitmap/header and the start of the actual radiotap field entries. This makes the radiotap calculations "right", so it correctly calculates where to overwrite the channel configuration. The long term fix is to go through and make each driver update the channel configuration, as some of the fields are already being updated. That, however, is a longer term fix that will need each driver fixed. I leave that as an exercise to someone in the future.
* Roll to the latest 2400/2500 firmware available from the public QLogicmjacob2012-06-172-42656/+43175
| | | | | | | website. Sponsored by: Spectralogic MFC after: 1 week
* libc: Reduce relative relocations in strftime().jilles2012-06-171-1/+1
|
* Prepare for FC-Tape support. This involved doing a lot of little cleanupsmjacob2012-06-176-357/+446
| | | | | | | | | | | | | | | | | | | | and crosschecks against firmware documentation. We now check and report FC firmware attributes and at least are now prepared for the upper 48 bits of f/w attributes (which are probably for the 8100 or later cards). This involed changing how inbits and outbits are calculated for varios commands, hopefully clearer and cleaner. This also caused me to clean up the actual mailbox register usage. Finally, we are now unconditionally using a CRN for initiator mode. A longstanding issue with the 2400/2500 is that they do *not* support a "Prefer PTP followed by loop", which explains why enabling that caused the f/w to crash. A slightly more invasive change is to let the firmware load entirely drive whether multi_id support is enabled or not. Sponsored by: Spectralogic MFC after: 1 week
* Don't check for race with close on advisory unlock (there is nothing smart wepjd2012-06-171-1/+2
| | | | | | | can do when such a race occurs). This saves lock/unlock cycle for the filedesc lock for every advisory unlock operation. MFC after: 1 month
* On certain newer Intel Atom based motherboards, for instance thephk2012-06-171-3/+10
| | | | | | | | | | | | | | | | | | | D2500CC which I have, syscons in text-mode fails to show the expected contents due to write errors into video-memory. At least one of the causes is that we copy from syscons internal buffer to the video memory with optimized bcopy(9) which uses >16bit operations. Until now, 32bit and wider operations have always worked on the video memory, but since I cannot find a single source which says that this SHALL work, and since these chipsets/bugs are now out there, this commit changes syscons to always use 16bit copies on i386 & amd64. This may be relevevant for PR's: 166262 166639 and various other bug reports floating elsewhere on the net, but I lack hardware to test those.
* Move the nfsrpc_close() call in ncl_reclaim() for the NFSv4 clientrmacklem2012-06-171-9/+9
| | | | | | | | to below the vnode_destroy_vobject() call, since that is where writes are flushed. Suggested by: kib MFC after: 1 week
* Extend the comment about checking for a race with close to explain whypjd2012-06-171-1/+17
| | | | | | | it is done and why we don't return an error in such case. Discussed with: kib MFC after: 1 month
* If VOP_ADVLOCK() call or earlier checks failed don't check for a race withpjd2012-06-171-0/+4
| | | | | | | close, because even if we had a race there is nothing to unlock. Discussed with: kib MFC after: 1 month
* Resotre LCD brightness level on resuming.iwasaki2012-06-171-0/+32
| | | | MFC after: 3 days
OpenPOWER on IntegriCloud