summaryrefslogtreecommitdiffstats
path: root/sys
Commit message (Collapse)AuthorAgeFilesLines
* Fix agp_nvidia.c to behave more like the linux driver, fixing DRI on Radeonanholt2005-09-162-22/+40
| | | | | | | | | | | | 9200 according to one responder. The primary issue was not setting some bits to say that the entries were active, but also fix one place where some memory wasn't being used as volatile as it should. While here, change some use of ffs to a relatively short case statement, to make it more obvious what's going on. PR: kern/71638, kern/72372, kern/71547? Submitted by: Andrew J. Caines <A.J.Caines@halplant.com>, Robin Schoonover <end@endif.cjb.net>, Jason Henson <jason@ec.rr.com>
* The arguments to printf() were swapped.ru2005-09-161-2/+2
|
* Break out of loop if next buffer pointer has become invalid while flushingtegge2005-09-161-0/+15
| | | | | | current buffer. Reviewed by: kan
* Fix "struct ifnet" leak if attach() fails in the middle.ru2005-09-165-3/+12
|
* Do assorted nitpicking in diagnostics while I'm here:yar2005-09-161-9/+9
| | | | | | - Use __func__ consistently instead of copying function name to message strings. Code tends to migrate around source files. - DIAGNOSTIC is for information, INVARIANTS is for panics.
* Avoid deferencing NULL in if_free().ru2005-09-161-3/+2
|
* It's nice to have relevant comments both in if {} and else {},yar2005-09-161-1/+4
| | | | not in just one of them.
* Test the new M_VLANTAG packet flag before callingyar2005-09-161-2/+5
| | | | | | | | | | m_tag_locate(). This adds little overhead of a simple bitwise operation in case hardware VLAN acceleration is on, yet saves the more expensive function call if the acceleration is off. Reviewed by: ru, glebius X-MFC-after: 6.0
* Fix "struct ifnet" leaks when attach() fails in the middle.ru2005-09-169-16/+31
|
* Fix "struct ifnet" leaks when attach() fails in the middle, e.g.ru2005-09-1617-40/+35
| | | | | | when mii_phy_probe() or bus_setup_intr() fails. For drivers that call their detach() in this case, call if_free() there to cover this case too.
* Fix "struct ifnet" leak on detach.ru2005-09-161-0/+1
|
* Add missing mtx_destroy() when if_alloc() fails.ru2005-09-166-4/+27
| | | | | Add missing if_free() when mii_phy_probe() fails. Put if_free() into the correct #ifdef in detach().
* Add missing if_free() in rue_detach().ru2005-09-161-0/+1
|
* Commit a workaround to a problem with resource allocation. This helpsimp2005-09-162-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | with some Dell servers that booted w/o a problem[*] on 5.4, but failed with 6.0-BETA. On the PCI bus, when we do lazy resource allocation, we narrow the range requested as we pass through bridges to reflect how the bridges are programmed and what addresses they pass. However, when we're doing an allocation on a bus that's directly connected to a host bridge, no such translation can take place. We already had a fallback range for memory requests, but none for ioports. As such, provide a fallback for I/O ports so we don't allocate location 0, which will have undesired side effects when the resources are actually used. This fixes a problem with booting a Dell server with usb in the kernel. However, it is an unsatisfying solution. I don't like the hard coded value, and I think we should start narrowing the resources returned to not be in the so-called isa alias area (where the ranage & 0x0300 must be 0 iirc). Doing such filtering will have to wait for another day. This may be a good 6 candidate, maybe after its had a chance to be refined. Tested by: glebius@
* plugged a possible memory leaksuz2005-09-161-1/+1
| | | | | Obtained from: KAME MFC after: 1 day
* Make the exploring of all luns supported by an HBA more of amjacob2005-09-161-5/+38
| | | | | | | | | | | | | | | tunable (until we get REPORT LUNS in place). If we're probing luns, and each probe succeeds, we keep going past lun 7 if we're a SCSI3 or better device (until we fail to probe). If we're probing luns, and a probe fails, we only keep going if we're quirked *for* it (CAM_QUIRK_HILUNS), and if we're not quirked *against* it (CAM_QUIRK_NOHILUNS), or we're a SCSI3 or better device and the tunable (kern.cam.cam_srch_hi) is set non-zero. Reviewed by: nate@rootlabs.org, gibbs@scsiguy.com, ken@kdm.com, scottl@samsco.org MFC after: 1 week
* Don't attempt to recurse lockmgr, it doesn't like it.phk2005-09-152-3/+6
|
* Fix race condition that caused activation of an event toups2005-09-151-2/+4
| | | | | | | be ignored immediately after it was deactivated. Found by: Yahoo! MFC after: 3 days
* Oops, missed adding the required include.jhb2005-09-151-0/+1
| | | | Pointy hat to: jhb
* Replace the dont_sleep_in_callout mutex hack (similar to g_x{up,down})jhb2005-09-151-8/+2
| | | | with the disallow sleeping facility.
* Don't disallow sleeping for handlers on swi's since some swi handlersjhb2005-09-151-2/+4
| | | | | | (like CAM) do sleep in their handlers. Requested by: scottl
* Add two missing if_free() calls.ru2005-09-151-0/+3
|
* Fixed a diagnostic message.ru2005-09-151-1/+1
|
* Spell "destroy" correctly.ru2005-09-152-2/+2
|
* Stop using the '+' constraint modifier with inline assembly. The '+'jhb2005-09-154-92/+102
| | | | | | | | | | constraint is actually only allowed for register operands. Instead, use separate input and output memory constraints. Education from: alc Reviewed by: alc Tested on: i386, alpha MFC after: 1 week
* Handle a race condition where NULLFS vnode can be cleaned while threadskan2005-09-151-4/+28
| | | | | | | can still be asleep waiting for lowervp lock. Tested by: kkenn Discussed with: ssouhlal, jeffr
* - Enforce an implicit lock order that Giant cannot be locked while holdingjhb2005-09-151-1/+17
| | | | | | | | | | any other non-sleepable lock. In plain English: Giant comes before all other mutexes. - Add some extra description to the lock order reversal printf's to indicate when a reversal is triggered by a hard-coded implicit rule. Requested by: truckman (2) MFC after: 1 week
* Don't recommend re_detach() (like in vr(4)) as anotherru2005-09-151-2/+1
| | | | | | | | | possible method to prevent panicing in interrupt handler after re_shutdown(), sometimes seen on SMP systems. This would work here only because re_detach() clears IFF_UP (to prevent another race) and it was demonstrated that it's not enough to call vr_detach() in vr_shutdown() to prevent a panic.
* - Add a new simple facility for marking the current thread as being in ajhb2005-09-154-31/+27
| | | | | | | | | | | | | state where sleeping on a sleep queue is not allowed. The facility doesn't support recursion but uses a simple private per-thread flag (TDP_NOSLEEPING). The sleepq_add() function will panic if the flag is set and INVARIANTS is enabled. - Use this new facility to replace the g_xup and g_xdown mutexes that were (ab)used to achieve similar behavior. - Disallow sleeping in interrupt threads when invoking interrupt handlers. MFC after: 1 week Reviewed by: phk
* - Adjust a comment, we do program the performance counter LVT entry nowjhb2005-09-151-3/+7
| | | | | | | | if hwpmc(4) is included. - Don't recursively panic if we are unable to send an IPI, just bail and hope for the best. MFC after: 1 week
* re_detach() fixes:ru2005-09-151-15/+7
| | | | | | | | | | | - Fixed if_free() logic screw-up that can either result in freeing a NULL pointer or leaking "struct ifnet". - Move if_free() after re_stop(); the latter accesses "struct ifnet". This bug was masked by a previous bug. - Restore the fix for a panic on detach caused by racing with BPF detach code by Bill by moving ether_ifdetach() after re_stop() and resetting IFF_UP; this got screwed up in revs. 1.30 and 1.36.
* When bus_alloc_resource_any() fails, dc_detach() is called and itkeramida2005-09-152-10/+22
| | | | | | | | | | attempts to deallocate busdma tags and resources that haven't been allocated yet, causing a panic every time a dc interface fails to attach. Fix by checking that we really have something to dealloc before calling bus_dma*() functions. Approved by: jhb MFC after: 1 week
* Explicitly switch to the new TSS by updating the current CPU's TSS selectorjhb2005-09-152-4/+7
| | | | | | | | | | | | | and reloading it in i386_extend_pcb() rather than trying to force a context switch to reload the TSS via the TDF_NEEDRESCHED flag. Optimizations to avoid calling cpu_switch() when the new thread was identical to the old thread defeated the attempt to force a TSS reload. Explicitly loading the new TSS is what we really want to do anyway. PR: i386/84842 Reported by: Alexander Best arundel at h3c dot de MFC after: 1 week Reviewed by: bde (mostly)
* - Fixup locking and mark MPSAFE.jhb2005-09-152-51/+58
| | | | | | | | - Use callout_init_mtx() and static callouts rather than timeout(). - m_getcl() in one place to simplify the code. Tested by: Gavin Atkinson gavin dot atkinson at ury dot york dot ac dot uk MFC after: 1 week
* Add a memory barrier for PREWRITE operations to ensure all writes by thejhb2005-09-151-0/+4
| | | | | | CPU have drained before further writes to kick off the operation. MFC after: 1 week
* The socket pointers in fifoinfo are not permitted to be NULL, sorwatson2005-09-151-5/+2
| | | | | | don't check if they are, it just confuses the fifo code more. MFC after: 3 days
* Improve the MP safeness associated with the creation of symboliccsjp2005-09-154-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | links and the execution of ELF binaries. Two problems were found: 1) The link path wasn't tagged as being MP safe and thus was not properly protected. 2) The ELF interpreter vnode wasnt being locked in namei(9) and thus was insufficiently protected. This commit makes the following changes: -Sets the MPSAFE flag in NDINIT for symbolic link paths -Sets the MPSAFE flag in NDINIT and introduce a vfslocked variable which will be used to instruct VFS_UNLOCK_GIANT to unlock Giant if it has been picked up. -Drop in an assertion into vfs_lookup which ensures that if the MPSAFE flag is NOT set, that we have picked up giant. If not panic (if WITNESS compiled into the kernel). This should help us find conditions where vnode operations are in-sufficiently protected. This is a RELENG_6 candidate. Discussed with: jeff MFC after: 4 days
* Add tnt4882 driver to the buildphk2005-09-152-3/+10
|
* First cut at a driver for National Instruments PCI-GPIB hardware.phk2005-09-151-0/+400
| | | | Hardware donated by: "Greg Maciejewski" <gregm@serverpit.com>
* Backout rev. 1.246, it breaks code uses shutdown(2) on non-connectedmaxim2005-09-151-2/+0
| | | | | | sockets. Pointed out by: rwatson
* Fix system shutdown timeout handling by again supporting longer runningrse2005-09-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | shutdown procedures (which have a duration of more than 120 seconds). We have two user-space affecting shutdown timeouts: a "soft" one in /etc/rc.shutdown and a "hard" one in init(8). The first one can be configured via /etc/rc.conf variable "rcshutdown_timeout" and defaults to 30 seconds. The second one was originally (in 1998) intended to be configured via sysctl(8) variable "kern.shutdown_timeout" and defaults to 120 seconds. Unfortunately, the "kern.shutdown_timeout" was declared "unused" in 1999 (as it obviously is actually not used within the kernel itself) and hence was intentionally but misleadingly removed in revision 1.107 from init_main.c. Kernel sysctl(8) variables are certainly a wrong way to control user-space processes in general, but in this particular case the sysctl(8) variable should have remained as it supports init(8), which isn't passed command line flags (which in turn could have been set via /etc/rc.conf), etc. As there is already a similar "kern.init_path" sysctl(8) variable which directly affects init(8), resurrect the init(8) shutdown timeout under sysctl(8) variable "kern.init_shutdown_timeout". But this time document it as being intentionally unused within the kernel and used by init(8). Also document it in the manpages init(8) and rc.conf(5). Reviewed by: phk MFC after: 2 weeks
* Allocate unit numbers with unr, implement detach function.phk2005-09-152-5/+21
|
* o Return ENOTCONN when shutdown(2) on non-connected socket.maxim2005-09-151-0/+2
| | | | | | | PR: kern/84761 Submitted by: James Juran R-test: tools/regression/sockets/shutdown MFC after: 1 month
* Various minor polishing.phk2005-09-153-22/+10
|
* Protect the devfs rule internal global lists with a sx lock, the perphk2005-09-151-1/+9
| | | | | mount locks are not enough. Finer granularity (x)locking could be implemented, but I prefer to keep it simple for now.
* Absolve devfs_rule.c from locking responsibility and call it withphk2005-09-153-19/+5
| | | | all necessary locking held.
* Retire unused dev_named() function.phk2005-09-152-14/+0
|
* Close a race which could result in unwarranted "ruleset %d alreadyphk2005-09-153-44/+34
| | | | | | | | | | | | | | | | | running" panics. Previously, recursion through the "include" feature was prevented by marking each ruleset as "running" when applied. This doesn't work for the case where two DEVFS instances try to apply the same ruleset at the same time. Instead introduce the sysctl vfs.devfs.rule_depth (default == 1) which limits how many levels of "include" we will traverse. Be aware that traversal of "include" is recursive and kernel stack size is limited. MFC: after 3 days
* When stopping the card, and returning to page 0, it is best if you doimp2005-09-151-1/+1
| | | | | | that with the NIC set of registers rather than the ASIC registers. I believe this was a harmless oversight, since we set ED_P0_CR to the same value 5ms later, but just to be safe...
* Fix so that when a slice or a partition is removed through g_slice_config(),rodrigc2005-09-141-0/+1
| | | | | | | | | | | | it is destroyed in GEOM, in addition to being removed from /dev. Before this patch, if you applied a new MBR which deleted a slice, the deleted slice would not be in /dev, but it would still appear in kern.geom.conftxt and kern.geom.confxml, which would confused the diskPartitionEditor in sysinstall. Submitted by: pjd Tested by: pjd, rodrigc MFC after: 1 week
OpenPOWER on IntegriCloud