Re: if_bge upload stalls repeatedly (Was: 8-STABLE outgoing scp stalling frequently)
On Wed, Feb 03, 2010 at 05:25:03PM -0800, Pyun YongHyeon wrote: > On Thu, Feb 04, 2010 at 11:52:55AM +1300, Jonathan Chen wrote: > > On Tue, Feb 02, 2010 at 11:20:29PM +0200, Nikos Ntarmos wrote: > > > On Wed, Feb 03, 2010 at 08:36:16AM +1300, Jonathan Chen wrote: > > > > Hi, > > > > > > > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > > > > stalling very frequently. This is the output from a "scp -v -v" > > > > of a 300Mb file from a local to a remote within an internal network: > > > > [...] > > > > Does anyone know what's happening here? Any tips on how to track down > > > > what the problem is? The network config appears to be fine - fetch(1) > > > > will > > > > have downloads speeds of up to 300KB/s. > > > > > > But how about upload speeds? It seems that's where scp is suffering as > > > well. > > > > This is the obvious test that I should have done; and you're hit the > > nail on the head. bge(4) on 8-STABLE (csup'd 4-Feb-2010) has a very > > bad upload speed. > > > > I've just tried using ftp to transfer some files: > > > > Upload speed: starts at 63 KB/s, falls rapidly before stalling. > > Download speeds: starts at 9 MB/s, increasing slightly before > > completing. > I'm not sure but recently added code to support TSO may cause the > issue. Would you show me verbose boot output(only bge(4) related > one)? bge0: mem 0xf1bf-0xf1bf irq 17 at device 0.0 on pci9 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0xf1bf bge0: adjust device control 0x2000 -> 0x5000 bge0: attempting to allocate 1 MSI vectors (1 supported) bge0: using IRQ 258 for MSI bge0: CHIP ID 0xa002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 bge0: bpf attached bge0: Ethernet address: 00:1d:09:d2:d1:9e bge0: [MPSAFE] bge0: [FILTER] bge0: Disabling fastboot bge0: Disabling fastboot bge0: link UP >To rule out possible TSO issue, disable TSO and try it > again(#ifconfig bge0 -tso). Does it make any difference? Yup, it sure does! With a TSO disabled, my upload and download speeds are pretty much symmetrical at a decent 10MB/s. Thanks! -- Jonathan Chen -- Do not take life too seriously. You will never get out of it alive. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: if_bge upload stalls repeatedly (Was: 8-STABLE outgoing scp stalling frequently)
On Thu, Feb 04, 2010 at 11:52:55AM +1300, Jonathan Chen wrote: > On Tue, Feb 02, 2010 at 11:20:29PM +0200, Nikos Ntarmos wrote: > > On Wed, Feb 03, 2010 at 08:36:16AM +1300, Jonathan Chen wrote: > > > Hi, > > > > > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > > > stalling very frequently. This is the output from a "scp -v -v" > > > of a 300Mb file from a local to a remote within an internal network: > > [...] > > > Does anyone know what's happening here? Any tips on how to track down > > > what the problem is? The network config appears to be fine - fetch(1) will > > > have downloads speeds of up to 300KB/s. > > > > But how about upload speeds? It seems that's where scp is suffering as > > well. > > This is the obvious test that I should have done; and you're hit the > nail on the head. bge(4) on 8-STABLE (csup'd 4-Feb-2010) has a very > bad upload speed. > > I've just tried using ftp to transfer some files: > > Upload speed: starts at 63 KB/s, falls rapidly before stalling. > Download speeds: starts at 9 MB/s, increasing slightly before completing. > I'm not sure but recently added code to support TSO may cause the issue. Would you show me verbose boot output(only bge(4) related one)? To rule out possible TSO issue, disable TSO and try it again(#ifconfig bge0 -tso). Does it make any difference? > Device from dmesg: > bge0: 0x00a002> mem 0xf1bf-0xf1bf irq 17 at device 0.0 on pci9 > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: if_bge upload stalls repeatedly (Was: 8-STABLE outgoing scp stalling frequently)
On Tue, Feb 02, 2010 at 11:20:29PM +0200, Nikos Ntarmos wrote: > On Wed, Feb 03, 2010 at 08:36:16AM +1300, Jonathan Chen wrote: > > Hi, > > > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > > stalling very frequently. This is the output from a "scp -v -v" > > of a 300Mb file from a local to a remote within an internal network: [...] > > Does anyone know what's happening here? Any tips on how to track down > > what the problem is? The network config appears to be fine - fetch(1) will > > have downloads speeds of up to 300KB/s. > > But how about upload speeds? It seems that's where scp is suffering as > well. This is the obvious test that I should have done; and you're hit the nail on the head. bge(4) on 8-STABLE (csup'd 4-Feb-2010) has a very bad upload speed. I've just tried using ftp to transfer some files: Upload speed: starts at 63 KB/s, falls rapidly before stalling. Download speeds: starts at 9 MB/s, increasing slightly before completing. Device from dmesg: bge0: mem 0xf1bf-0xf1bf irq 17 at device 0.0 on pci9 -- Jonathan Chen -- "I don't want to achive immortality through my works.. I want to achieve it through not dying" - Woody Allen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
messages output starts getting interleaved
Hello. After migrating to 8.0-STABLE from 7.2-STABLE my messages output starts getting interleaved (see below). I'm running amd64 smp kernel. Is there anything can be done to get rid of this? Thanks in advance. Feb 3 19:44:49 tiger named[989]: running Feb 3 19:44:50 tiger ntpd[1179]: ntpd 4.2.4p5-a (1) Feb 3 19:44:50 tiger dhcpd: Feb 3 19:44:50 tiger kernel: a Feb 3 19:44:50 tiger kernel: <1 Feb 3 19:44:50 tiger dhcpd: No subnet declaration for rl0 (193.200.85.132). Feb 3 19:44:50 tiger dhcpd: ** Ignoring requests on rl0. If this is not what Feb 3 19:44:50 tiger dhcpd:you want, please write a subnet declaration Feb 3 19:44:50 tiger kernel: <118<>Fe1b 31 8>S1e9n:di4n4g: 5o0n t i gSeorc kdehtc/pfadl:l b a c ky/ofua wlanlt,b palecask-e nwreitt Feb 3 19:44:50 tiger kernel: e Feb 3 19:44:50 tiger dhcpd:in your dhcpd.conf file for the network segment Feb 3 19:44:50 tiger dhcpd:to which interface rl0 is attached. ** Feb 3 19:44:50 tiger dhcpd: ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bsnmpd returns incorrect hrProcessorLoad values
En/na Mikolaj Golub ha escrit: > On Fri, 29 Jan 2010 12:37:52 +0100 Gustau Pérez wrote: > > >> Hi, >> >> I'm using cacti to monitor some servers running FBSD. I was using 7.2 >> with SCHED_4BSD. With this configuration : bsnmpd+bsnmp-ucd was >> returning right values for the cores' load. >> >>I recently updated the servers (via csup) to RELENG_8 and bsnmpd is >> returning negative values for the cores' load. If I try something like >> in a 4-core system : >> >> snmpwalk -v 2c -c community server .1.3.6.1.2.1.25.3.3.1 >> >>what I get is : >> >> .1.3.6.1.2.1.25.3.3.1.1.6 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.1.10 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.1.14 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.1.18 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.2.6 = INTEGER: -182 >> .1.3.6.1.2.1.25.3.3.1.2.10 = INTEGER: -182 >> .1.3.6.1.2.1.25.3.3.1.2.14 = INTEGER: -182 >> .1.3.6.1.2.1.25.3.3.1.2.18 = INTEGER: -182 >> >> I tried and old bsnmpd-ucd (0.2.1, works fine in a 7,2 system) with a >> 8.0 system. Same wrong results. And it seems bsnmpd in /usr/src/contrib >> has not changed between 7.2 and 8.0. >> >> Any ideas ? I'm not an expert, but with tcpdump I see different >> results. Against an old 7.2 system, the field related to each core load >> gives the right value. Instead, against and 8.0 system, those field show >> (in hex) values like fd 4b. What I don't know is how bsdnmp-ucb retrives >> those values and how it construct the udp response packet. >> > > bsnmpd-ucd has nothing to do with HOST-RESOURCES-MIB. These mibs are provided > by snmp_hostres(3) module (/usr/lib/snmp_hostres.so). So something wrong is > there (I suppose it is not in sync with some recent changes in kernel or > libkvm). > > You are right. I checked the usr.sbin/bsnmpd/modules/snmp_hostres/hostres_processor_tbl.c. I think it has something to do with the processor_getpcpu function (line 122). The code is : > if (ccpu == 0 || fscale == 0) > return (0.0); > > #define fxtofl(fixpt) ((double)(fixpt) / fscale) > return (100.0 * fxtofl(ki_p->ki_pctcpu) / > (1.0 - exp(ki_p->ki_swtime * log(fxtofl(ccpu); With 4 core SCHED_ULE system I checked it and ccpu is always 0 (sysctl kern.ccpu gives 0 too). So this routine always returns 0.0. That makes the save_sample routine to fill e->samples[#cpu] with 100. If I comment the ccpu ==0, the I see strange values. I know, I changed the code. With some printfs, I see the returned value when starting bsnmpd is 98~99. But the it goes up until 350~400 (strange). I put some others printfs and then I saw that when starting the daemon it return 98~99 for each processor and the ki_pctcpu is 2026 (in my case). Then, the next time bsnmpd refreshes its values I see it returns wrong values and ki_pctcpu goes up four times. So the function returns nearly 400% of idle time for each processor... So I checked it with SCHED_4BSD with an 8 core system. The same behaviour, but this time I got an increase of eight times for the ki_pctcpu. Now I'm stuck in here. I think the kinfo_proc info is obtained ny using kvm_getprocs. Do you have any idea why it returns those values ? Regards, Gus - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Inmutable bit in some binaries
On Wed, Feb 03, 2010 at 01:33:15PM +0100, Jordi Espasa Clofent wrote: > HI all, > > I'm hardening one test box and at present I'm planning to do: > > # chflags -R schg > > where will be some binaries that seems to be common targets > for rootkits and lammers: > > ls > du > ps > find > top > locate > strings > ifconfig > netstat login > > I wonder if changing these files permissions as I've shown above > will be cause some troubles in future upgrade (recompilation, the > classic way, not the binary upgrade one) process. ¿It will? It's possible installworld will break (fail/exit) when trying to overwrite some of these binaries. However... install(1) supports the -f flags to specify what the destination file should have its file flags (chflags) set to, and from looking at the code (src/usr.bin/xinstall/xinstall.c), there are some places which indicate before copying/installing a file the software may attempt to unset file flags first. I'm not 100% familiar with this code, but it appears as if use of the -S flag to install(1) would cause it to behave like described. It should be easy enough for you to test. Otherwise, my recommendation is to build a test system / virtual box of some sort (VMware, etc.) and try it. See what happens. Opinion below: What you're attempting to solve, ultimately, is security through obscurity and gets you a very large headache. :-) Your schg idea would only work if you planned on using kern.securelevel=1 or higher. This sounds great in concept, but many a time on this list have people posted problems with system administrative tasks (re: upgrading) when this sysctl is set to non-default (-1). If you plan on using this, I would advocate *all* installation/work be done in single-user mode. I know quite a few people who completely ignore the "boot into single user" step of src/Makefile and instead do it in multi-user mode -- only to be found later screaming/crying when binaries don't work or behave oddly because, say, /libexec/ld-elf.so was supposed to be updated yet wasn't due to their choosing to not follow the proper procedure. If your system doesn't have an out-of-band method of getting to it (ex. serial console), then I wouldn't bother trying any of the above. Otherwise, I'm pretty sure others here have made use of read-only environments, such as read-only NFS root filesystems (sometimes accomplished via PXE) and/or /usr, or CD-based OS (good luck changing any files there). I can't help in that regard. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Inmutable bit in some binaries
HI all, I'm hardening one test box and at present I'm planning to do: # chflags -R schg where will be some binaries that seems to be common targets for rootkits and lammers: ls du ps find top locate strings ifconfig netstat login I wonder if changing these files permissions as I've shown above will be cause some troubles in future upgrade (recompilation, the classic way, not the binary upgrade one) process. ¿It will? -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ionice in FreeBSD?
On 02/03/2010 12:12 PM, Bruce Simpson wrote: On 02/02/2010 17:19, Jordi Espasa Clofent wrote: In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if I'm understanding correctly, they're related to CPU priorty only, not to I/O. That's not entirely true. A thread's CPU priority is still going to affect its ability to be scheduled on the CPU, and if it's waiting in the read() or write() syscalls, then this will make a difference to how quickly it can complete the next call. Yes. I've already supposed it. However, it doesn't explicitly affect relative I/O prioritization. This is another story entirely. I suspect in a lot of cases adding a weight to per thread I/O, isn't going to make much difference for disk I/Os which are being sorted for the geometry (e.g. AHCI NCQ). So I guess my question is, 'why do you need I/O scheduling, and what aspect of system performance are you trying to solve with it' ? Some shell-scripts based on dd or rsync, for example. Even a daily antivirus (ClamAV) scanner means an extensive I/O. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ionice in FreeBSD?
On 02/02/2010 17:19, Jordi Espasa Clofent wrote: In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if I'm understanding correctly, they're related to CPU priorty only, not to I/O. That's not entirely true. A thread's CPU priority is still going to affect its ability to be scheduled on the CPU, and if it's waiting in the read() or write() syscalls, then this will make a difference to how quickly it can complete the next call. However, it doesn't explicitly affect relative I/O prioritization. This is another story entirely. I suspect in a lot of cases adding a weight to per thread I/O, isn't going to make much difference for disk I/Os which are being sorted for the geometry (e.g. AHCI NCQ). So I guess my question is, 'why do you need I/O scheduling, and what aspect of system performance are you trying to solve with it' ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
Dan Naumov wrote:
> [j...@atombsd ~]$ dd if=/dev/zero of=/home/jago/test2 bs=1M count=4096
> 4096+0 records in
> 4096+0 records out
> 4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec)
>
> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and
> 4GB in 143.8 seconds / 28,4mb/s
For the record, better results can be seen. In my test I put 3 Seagate
Barracuda XT drives in a port multiplier and connected that to one port
of a PCIe 3124 card.
The MIRROR case is at about the I/O bandwidth limit of those drives.
[r...@kraken ~]# zpool create tmpx ada{2,3,4}
[r...@kraken ~]# dd if=/dev/zero of=/tmpx/test2 bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 20.892818 secs (205571470 bytes/sec)
[r...@kraken ~]# zpool destroy tmpx
[r...@kraken ~]# zpool create tmpx mirror ada{2,3}
[r...@kraken ~]# dd if=/dev/zero of=/tmpx/test2 bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 36.432818 secs (117887321 bytes/sec)
[r...@kraken ~]#
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nmi_calltrap in siopoll()
kern/143521
2010/2/2 pluknet :
> Hi.
>
> I've got NMI on an almost idle system - FreeBSD 7.2-R amd64.
> I guess the reason may be in (hardware?) binary garbage
> seen once in a while on serial port (loader, then ttyd0).
> Ask me for more details.
>
> Tracing command swi4: clock sio pid 20 tid 100011 td 0xff000144e370
> cpustop_handler() at cpustop_handler+64
> ipi_nmi_handler() at ipi_nmi_handler+48
> trap() at trap+796
> nmi_calltrap() at nmi_calltrap+8
> --- trap 19, rip = 18446744071567390785, rsp = 18446744067267268592,
> rbp = 18446744067267558272 ---
> _mtx_lock_spin() at _mtx_lock_spin+113
> siopoll() at siopoll+206
> ithread_loop() at ithread_loop+384
> fork_exit() at fork_exit+287
> fork_trampoline() at fork_trampoline+14
> --- trap 0, rip = 0, rsp = 18446744067267558704, rbp = 0 ---
>
> (kgdb) thr 13
> [Switching to thread 13 (Thread 100011)]#0 cpustop_handler () at atomic.h:264
> 264 atomic.h: No such file or directory.
> in atomic.h
> (kgdb) bt
> #0 cpustop_handler () at atomic.h:264
> #1 0x807ec400 in ipi_nmi_handler ()
> at /usr/src/sys/amd64/amd64/mp_machdep.c:1144
> #2 0x807fceec in trap (frame=0xfffe80028f40)
> at /usr/src/sys/amd64/amd64/trap.c:198
> #3 0x807e0aeb in nmi_calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:427
> #4 0x80513841 in _mtx_lock_spin (m=0x80bb3d00,
> tid=18446742974219215728, opts=Variable "opts" is not available.
> ) at /usr/src/sys/kern/kern_mutex.c:474
> #5 0x8082b96e in siopoll (dummy=Variable "dummy" is not available.
> ) at /usr/src/sys/dev/sio/sio.c:1703
> #6 0x804ff940 in ithread_loop (arg=0xff000142bac0)
> at /usr/src/sys/kern/kern_intr.c:1088
> #7 0x804fc1df in fork_exit (
> callout=0x804ff7c0 , arg=0xff000142bac0,
> frame=0xfffe8006fc80) at /usr/src/sys/kern/kern_fork.c:834
> #8 0x807e0b5e in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:455
> #9 0x in ?? ()
> #10 0x in ?? ()
> #11 0x0001 in ?? ()
> #12 0x in ?? ()
> #13 0x in ?? ()
> #14 0x in ?? ()
> ---Type to continue, or q to quit---q
> Quit
> (kgdb) f 5
> #5 0x8082b96e in siopoll (dummy=Variable "dummy" is not available.
> ) at /usr/src/sys/dev/sio/sio.c:1703
> 1703 mtx_lock_spin(&sio_lock);
> (kgdb) i loc
> _tid = Variable "_tid" is not available.
> (kgdb) list
> 1698 com_events -= incc;
> 1699 mtx_unlock_spin(&sio_lock);
> 1700 continue;
> 1701 }
> 1702 if (com->iptr != com->ibuf) {
> 1703 mtx_lock_spin(&sio_lock);
> 1704 sioinput(com);
> 1705 mtx_unlock_spin(&sio_lock);
> 1706 }
> 1707 if (com->state & CS_CHECKMSR) {
> (kgdb) p sio_lock
> $1 = {lock_object = {lo_name = 0x80b15380 "sio",
> lo_type = 0x80b15380 "sio", lo_flags = 458752, lo_witness_data = {
> lod_list = {stqe_next = 0x0}, lod_witness = 0x0}},
> mtx_lock = 18446742974219094608, mtx_recurse = 0}
> (kgdb) p/x sio_lock->mtx_lock
> $10 = 0xff0001430a50 # == td for pid 17 tid 18
>
>
> Binary garbage is like below (not touching anything on k/board atm).
>
> login:
> FreeBSD/amd64 (ho
> FreeBSD/amd64 (host) (ttyd0)
>
> login: <<|Ч
> FreeBSD
> FreeBSD
> FreeBS
> FreeBSD
> Free
> FreeBSD/amd64 (host) (ttyd0)
>
> login:
> FreeBSD/amd64 (host) (ttyd0)
>
> login:
> FreeBSD
> Free
>
> FreeBS
> FreeBSD
> FreeBS
> FreeBSD
> FreeBSD
> FreeBS
> FreeBSD
> FreeBS
> FreeBSD
> FreeBSD
> FreeBS
> FreeBSD
> FreeBS═╗Hхи M5
> FreeBSD
> FreeBS
> FreeBSD
> FreeBSD
> FreeBS
> FreeBSD
> FreeBS═╗Hхи M5
> FreeBSD
> FreeBS
> FreeBSD
> FreeB
> FreeBSD/amd6
> FreeBS
> FreeBS
> FreeBSD
> FreeBSD
> FreeBS
> FreeBSD
> FreeBS
> FreeBSD
> FreeBSD
> FreeBS
> FreeBSD
> FreeBS═╗Hхи M5
> FreeBSD
> FreeBS
> FreeBSD
> [..a little later..]
>
> [r...@host ~]# <<<>8<8
> <8<<<><
>
> Other useful stuff.
>
> (kgdb) f 4
> #4 0x80513841 in _mtx_lock_spin (m=0x80bb3d00,
> tid=18446742974219215728, opts=Variable "opts" is not available.
> ) at /usr/src/sys/kern/kern_mutex.c:474
> 474 while (m->mtx_lock != MTX_UNOWNED) {
> (kgdb) list
> 469 lock_profile_obtain_lock_failed(&m->lock_object,
> &contested, &waittime);
> 470 while (!_obtain_lock(m, tid)) {
> 471
> 472 /* Give interrupts a chance while we spin. */
> 473 spinlock_exit();
> 474 while (m->mtx_lock != MTX_UNOWNED) {
> 475 if (i++ < 1000) {
> 476 cpu_spinwait();
> 477
