Searched hist:431 (Results 1 - 5 of 5) sorted by relevance

/src/sys/dev/ic/
H A Dcacreg.h1.5 Wed Jan 10 16:48:04 GMT 2001 ad branches: 1.5.24; 1.5.32; 1.5.34;
Make this work with the SA 431 and 42xx series controllers.
/src/sys/dev/pci/
H A Dcac_pci.c1.10 Wed Jan 10 16:48:04 GMT 2001 ad branches: 1.10.2; 1.10.4;
Make this work with the SA 431 and 42xx series controllers.
1.5 Fri Sep 01 00:13:08 GMT 2000 ad - Interface cleanup. static, const in places.
- cac_pci_l0 has been moved to cac.c, since it's useful for EISA boards.
- Model-specific linkage now is responsible for DMA synchronization.
- If we don't recognise the board, print the subsystem ID.
- Add support for RAID LC2 and Smart Array 431.
- Start firmware background tasks on controllers that need it.
/src/sbin/umount/
H A Dumount.c1.9 Thu Aug 25 02:14:01 GMT 1994 cgd branches: 1.9.2;
several fixes from Mark Weaver <mhw@cs.brown.edu>, relating to error
reporting. (pr 431)
/src/sys/rump/librump/rumpkern/
H A Dlwproc.c1.59 Sun Apr 06 01:13:55 GMT 2025 riastradh rump: Nix leaked struct lwp on every rump_server syscall.

This leak was introduced by lwproc.c rev. 1.51 back in 2020, when the
kmem_zalloc(sizeof(*l), KM_SLEEP) was factored out of callers and
into lwproc_makelwp:

-static void
-lwproc_makelwp(struct proc *p, struct lwp *l, bool doswitch, bool procmake)
+static struct lwp *
+lwproc_makelwp(struct proc *p, bool doswitch, bool procmake)
{
+ struct lwp *l = kmem_zalloc(sizeof(*l), KM_SLEEP);
...
@@ -435,8 +431,12 @@ rump_lwproc_newlwp(pid_t pid)
kmem_free(l, sizeof(*l));
return EBUSY;
}
+ mutex_exit(p->p_lock);
mutex_exit(&proc_lock);
- lwproc_makelwp(p, l, true, false);
+
+ /* XXX what holds proc? */
+
+ lwproc_makelwp(p, true, false);

Unfortunately, the kmem_zalloc in rump_lwproc_newlwp was not deleted.
So it just leaked.

And this routine is called on _every_ syscall handled by rump_server
(via struct rumpuser_hyperup::hyp_lwproc_newlwp):

674 static void
675 serv_handlesyscall(struct spclient *spc, struct rsp_hdr *rhdr, uint8_t *data)
676 {
677 register_t retval[2] = {0, 0};
678 int rv, sysnum;
679
680 sysnum = (int)rhdr->rsp_sysnum;
681 DPRINTF(("rump_sp: handling syscall %d from client %d\n",
682 sysnum, spc->spc_pid));
683
=> 684 if (__predict_false((rv = lwproc_newlwp(spc->spc_pid)) != 0)) {
685 retval[0] = -1;
686 send_syscall_resp(spc, rhdr->rsp_reqno, rv, retval);
687 return;
688 }
689 spc->spc_syscallreq = rhdr->rsp_reqno;
690 rv = rumpsyscall(sysnum, data, retval);

https://nxr.netbsd.org/xref/src/lib/librumpuser/rumpuser_sp.c?r=1.77#684

So this leak would grow fairly quickly in processes issuing rump
syscalls to rump_servers, which t_sp:sigsafe's helper h_sigcli does
as fast as it can in a loop for 5sec -- which is just long enough for
the i386 releng testbed with about 128 MB of RAM to run out of memory
in roughly half of the test runs, but not long enough on my laptop
with 64 GB of RAM to ever reproduce the problem.

Found by:

(a) running the test for 20sec rather than 5sec to amplify the leak;
(b) counting bytes allocated by return addresses of rumpuser_malloc;
(c) chasing that to rump_hypermalloc (culprit) vs uvm_km_alloc;
(d) chasing that to pgctor, uvm_map, uvm_km_kmem_alloc (culprit),
vmapbuf;
(e) then to pool_page_alloc, then to pool_allocator_alloc, then to
pool_grow, then to pool_get, then to pool_cache_get, then to
kmem_zalloc;
(f) finally to the call to kmem_zalloc in rump_lwproc_newlwp, which
at last yielded to my stare.

This instrumentation was extremely ad hoc -- I just created a table
of 4096 entries for each routine, and populated by linear scan with
atomics:

struct {
void *volatile ra;
volatile unsigned long n;
} pool_cache_get_bytes;

void *
kmem_zalloc(size_t size, km_flags_t flags)
{
...
void *const ra = __builtin_return_address(0);
size_t i;
for (i = 0; i < __arraycount(kmem_zalloc_bytes); i++) {
if (pool_cache_get_bytes[i].ra == ra ||
(pool_cache_get_bytes[i].ra == NULL &&
atomic_cas_ptr(&pool_cache_get_bytes[i].ra, NULL,
ra) == NULL)) {
atomic_add_long(&pool_cache_get_bytes[i].n, size);
break;
}
}
...
}

Would be nice to systematize this. Would also be nice to bring back
malloc tags for accounting purposes so you don't need to match up the
kmem_zalloc return addresses with the kmem_free return addresses to
find leaks -- I got lucky here because there were very few return
addresses to piece through.

PR misc/59252: tests/rump/rumpkern/t_sp:sigsafe: out of memory
/src/sys/dev/scsipi/
H A Dscsiconf.c1.37 Wed Jul 12 09:56:09 GMT 1995 cgd add/change a few quirks:
(1) all Chinon CDS-431 CD-ROMs (regardless of revision)
are forced to only having LUN 0, at the suggestion
of Michael Hitch.
(2) _force_ searching of extra LUNs for the Emulex MD21/S2
ESDI bridge. It's pre-SCSI 1, but knows about LUNs.
"amazing." From Jason Thorpe.
(3) recognize an Emulex tape adapter in front of a QIC-36
tape, and have it forced to only LUN 0. This is
an odd one; vendor, name, and rev strings are all
spaces. Anything that mathes this is very likely
broken, anyway, so might as well give it a shot.
Again from Jason Thorpe.

Completed in 36 milliseconds