Re: SBLive... anyone, anywhere?
There was some mention in the SBLive earlier this year (January), whatever became of it? I checked www.posi.net and I do not see the driver listed there at all. Pointers/suggestions? it's listed there. the guy does not reply the mails, however -- mauzi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem size limit?
On Wed, 16 Feb 2000, Dan Nelson wrote: :In the last episode (Feb 16), Greg Lehey said: : On Tuesday, 15 February 2000 at 3:40:58 -0600, Joe Greco wrote: : : Dunno how many terabyte filesystem folks are out there. : : None, by the looks of it. : :Possibly no FreeBSD folks, but on Solaris, VXFS scales very well to :large volumes. We've got 2TB worth of storage on a pair of Sparcs, and :we probably could have created two 1TB filesystems. We went with 200gb :and 100gb volumes instead, for ease of backup. We had a 2TB FS on an Origin2000 at NASA. Jamie Bowden -- "Of course, that's sort of like asking how other than Marketing, Microsoft is different from any other software company..." Kenneth G. Cavness To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
dc / de device probing
Hi, I recently got this DEC PC which has an 21142 ethernet chip onboard. Using -current's dc driver I get: Feb 17 19:37:39 p6 /kernel: Correcting Natoma config for non-SMP Feb 17 19:37:39 p6 /kernel: dc0: Intel 21143 10/100BaseTX port 0xec00-0xec7f m em 0xfdfffc00-0xfdfffc7f irq 11 at device 3.0 on pci0 Feb 17 19:37:39 p6 /kernel: dc0: Ethernet address: 00:00:f8:75:3c:6a Feb 17 19:37:39 p6 /kernel: miibus0: MII bus on dc0 Feb 17 19:37:39 p6 /kernel: dcphy0: Intel 21143 NWAY media interface on miibus 0 Feb 17 19:37:39 p6 /kernel: dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX- FDX, auto Using the de driver one gets: Feb 17 19:54:17 p6 /kernel: Correcting Natoma config for non-SMP Feb 17 19:54:17 p6 /kernel: de0: Digital 21142 Fast Ethernet port 0xec00-0xec7 f mem 0xfdfffc00-0xfdfffc7f irq 11 at device 3.0 on pci0 Feb 17 19:54:17 p6 /kernel: de0: DEC 21142 [10-100Mb/s] pass 1.1 Feb 17 19:54:17 p6 /kernel: de0: address 00:00:f8:75:3c:6a Feb 17 19:54:17 p6 /kernel: de0: driver is using old-style compatability shims The interesting thing is that the de driver works, the dc does not: Feb 17 19:38:48 p6 login: ROOT LOGIN (root) ON ttyv0 Feb 17 19:39:40 p6 /kernel: dc0: watchdog timeout Feb 17 19:40:02 p6 /kernel: dc0: watchdog timeout The machine has it's 21142 connected to a bulkhead panel with a UTP/10base2 connector. It cannot (unless the panel is swapped for a 100mbit one) do 100mbit UTP. What I wonder: why is the dc driver detecting a 21143 whereas the de sees a 21142 (which is the correct one BTW)? Are the chips not well enough distinguishable from the hardware perspective? Wilko -- Wilko Bulte Arnhem, The Netherlands WWW : http://www.tcja.nlThe FreeBSD Project: http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
64bit OS?
Just read this article: http://www.zdnet.com/zdnn/stories/news/0,4586,2440002,00.html Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? Waiting for somebody at Intel to give us either hardware or simulator time. Without either of those things, "working on" Itanium support is a pretty pointless exercise. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
On Thu, Feb 17, 2000 at 02:26:16PM -0800, Jordan K. Hubbard wrote: Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? Waiting for somebody at Intel to give us either hardware or simulator time. Without either of those things, "working on" Itanium support is a pretty pointless exercise. A pretty tricky exercise also. Thanks for the quick response Jordan. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Just read this article: http://www.zdnet.com/zdnn/stories/news/0,4586,2440002,00.html Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? Considering the fact that Intel released the IA-64 OS info only on the 15th, and, to my knowledge, haven't signed any NDA's with anyone from the FreeBSD team, I'd assume that we're precisely nowhere. ;) Having said that, I'll be getting Itanium hardware fairly soon after it's avaliable outside of Intel, and would be ultra-happy to work on an IA-64 FreeBSD when that happens. In the meantime, the only alternative would be to convince Intel to give someone their IA-64 SimOS, but there's an extermely slim chance of that happening (from talking to someone on the IA-64 team.) Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Patryk Zadarnowski wrote: FreeBSD when that happens. In the meantime, the only alternative would be to convince Intel to give someone their IA-64 SimOS, but there's an extermely slim chance of that happening (from talking to someone on the IA-64 team.) An alternative to IA-64 is the alpha processor. Last time I checked, FreeBSD ran just peachy on a 64-bit processor. ;-) Check out Cmpaq's test drive program. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Patryk Zadarnowski wrote: FreeBSD when that happens. In the meantime, the only alternative would be to convince Intel to give someone their IA-64 SimOS, but there's an extermely slim chance of that happening (from talking to someone on the IA-64 team.) An alternative to IA-64 is the alpha processor. Last time I checked, FreeBSD ran just peachy on a 64-bit processor. ;-) Check out Cmpaq's test drive program. I don't know... I'm still to get it to boot on mine (NetBSD runs fine, but for some bizzare reason, FreeBSD insists on a serial console ;) Anyway, alphas are boring compared to Itanium. What else can you say about a chip with 3MB of L3 cache on the die, a four clock cycle latency to carry the signal from one end of the chip to the other, and the main design limitation being the US power supplies? :) Not to mention the fact that Intel isn't even planning to release any single-cpu system Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
An alternative to IA-64 is the alpha processor. Last time I checked, FreeBSD ran just peachy on a 64-bit processor. ;-) Check out Cmpaq's test drive program. I don't know... I'm still to get it to boot on mine (NetBSD runs fine, but for some bizzare reason, FreeBSD insists on a serial console ;) Anyway, alphas are boring compared to Itanium. What else can you say about a chip with 3MB of L3 cache on the die, a four clock cycle latency to carry the signal from one end of the chip to the other, and the main design limitation being the US power supplies? :) Not to mention the fact that Intel isn't even planning to release any single-cpu system What can one say to that, apart from "I have one right here and it works just fine" - not something you can say about the IA-64. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? Waiting for somebody at Intel to give us either hardware or simulator time. Without either of those things, "working on" Itanium support is a pretty pointless exercise. Just a thought: One could use the released 64-bit Itanium gcc, create a i386-itanium crosscompiler, and start preparing some stuff? Marco van de Voort ([EMAIL PROTECTED]) http://www.stack.nl/~marcov/xtdlib.htm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
stuck NFS procs
This is only the second time ever this has happened, but it is still an interesting problem... I have a large number of "emacs" processes stuck in disk-wait. Here is the ps axl line for one such process: 33639 88194 1 0 -22 0 5856 340 vmpfw D qi- 0:01.34 emacs proxy. Any attempt to access emacs on the client system would result in a type of hang for that process. Here is a 'cat /usr/local/bin/emacs /dev/null': 2371 90317 1 3 -18 0 2688 pgtblk D p4- 0:00.02 cat /usr/loc To "fix" this I went to the NFS server and 'cp emacs emacs.new;rm emacs;mv emacs.new emacs'. In essence forcing a new FH. The old procs still stick arround. This leads me to believe the problem is entirely on the local system (ie, the kernel isn't asking for pages from the NFS server for that FH) Any ideas what could be corrupting the local cache (I am assuming that is the problem) like this. Nothing of note in the dmesg. -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
- Original Message - From: "Marco van de Voort" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 17, 2000 3:30 PM Subject: Re: 64bit OS? Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? Waiting for somebody at Intel to give us either hardware or simulator time. Without either of those things, "working on" Itanium support is a pretty pointless exercise. Just a thought: One could use the released 64-bit Itanium gcc, create a i386-itanium crosscompiler, and start preparing some stuff? Marco van de Voort ([EMAIL PROTECTED]) http://www.stack.nl/~marcov/xtdlib.htm The difficult bits rarely have anything to do with compilers and such (especially given that most of the code has been through a 64-bit port to the alpha). The system-mode pieces of IA-64/Merced were not public until recently; I noticed the full document set just became available on the intel web site this week. There's also the Linux port that was posted to the web in the past week or two; that should show what's needed for a FreeBSD port. Of course, as was mentioned before, without hardware or a simulator it's pretty pointless to put much effort into something like this. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
On Fri, 18 Feb 2000, Patryk Zadarnowski wrote: I don't know... I'm still to get it to boot on mine (NetBSD runs fine, but for some bizzare reason, FreeBSD insists on a serial console ;) Anyway, alphas are boring compared to Itanium. What else can you say about a chip with 3MB of L3 cache on the die, a four clock cycle latency to carry the signal from one end of the chip to the other, and the main design limitation being the US power supplies? :) Not to mention the fact that Intel isn't even planning to release any single-cpu system "I could have had a PA-8600!"? Today, and not at some vague point in the future? David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? Waiting for somebody at Intel to give us either hardware or simulator time. Without either of those things, "working on" Itanium support is a pretty pointless exercise. Just a thought: One could use the released 64-bit Itanium gcc, create a i386-itanium crosscompiler, and start preparing some stuff? Marco van de Voort ([EMAIL PROTECTED]) http://www.stack.nl/~marcov/xtdlib.htm The difficult bits rarely have anything to do with compilers and such (especially given that most of the code has been through a 64-bit port to the alpha). The system-mode pieces of IA-64/Merced were not public until recently; I noticed the full document set just became available on the intel web site this week. There's also the Linux port that was posted to the web in the past week or two; that should show what's needed for a FreeBSD port. The Linux port is extremely minimalistic and uses the minimum amout of IA-64 features to get the OS to do anything useful. Of course, as was mentioned before, without hardware or a simulator it's pretty pointless to put much effort into something like this. Also, you'll find that the actual silicon is somewhat different from the documentation: whole chunks of the architecture are either unimplemented or covered by errata, and not planned to be fixed in the public Itanium silicon. The OS teams that signed NDAs with Intel (including the Linux team: most of their code has been written by IA-64 teams at Intel and HP) have been cooperating very closely with Intel and were given a lot of information that (most of us) can only dream about. That is to say: even the simulator wouldn't help much right now. On the other hand, IA-64 is a very exotic architecture from the OS's point of view, and anyone planning to port *BSD to it should probably start planning ASAP. Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
"I could have had a PA-8600!"? Today, and not at some vague point in the future? That sort-of misses the point, as I'm taking a research OS perspective, where IA-64 is trully unique in terms of versitality and a well thought-through design (especially when it comes to SASOS support!) Besides, that point in the future is not all that vague at all ;) Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
What can one say to that, apart from "I have one right here and it works just fine" - not something you can say about the IA-64. 8) I'll just reach down and pat my trusty pair of manufactured-in-1993 Alpha 3000's on their heads... :) Oh, forgot... It's not new until Intel does it... sorry... mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
What can one say to that, apart from "I have one right here and it works just fine" - not something you can say about the IA-64. 8) I'll just reach down and pat my trusty pair of manufactured-in-1993 Alpha 3000's on their heads... :) Oh, forgot... It's not new until Intel does it... sorry... mike You're being just plain silly. It takes about 5 minutes with the manuals to realize just how little AXP and IA-64 have in common: one is a classic superscalar out-of-order design, the other is just about the opposite: a typical explicit-ILP architecture. What makes IA-64 great is the 8 years of statistical analysis of real-life software the architecture design team spent fine-tuning the instruction set. What makes AXP great is the clock rates Digital/Compaq manages to pump into the beasts ;) And no, there's nothing fundamentally new in IA-64 apart from the fact that they're the last kids on the block with a 64 bit chip ;) Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: stuck NFS procs
I'd say this is more likely a VM bug rather then an NFS bug. I don't think anything is being corrupted, I think it may just be a deadlock. For this sort of problem you should be able to gdb the kernel live on the system (without core'ing it) and then look at the stack backtrace for the processes in question. You need a debug version of the kernel binary that is running. gdb -k kernel.debug /dev/mem proc 88194 back proc 90317 back Also do your ps axl again and make sure there aren't any other processes stuck in an odd state, looking at the code I don't see a possible deadlock between those two blocking states. -Matt Matthew Dillon [EMAIL PROTECTED] :This is only the second time ever this has happened, but it is still an :interesting problem... I have a large number of "emacs" processes stuck in :disk-wait. Here is the ps axl line for one such process: : :33639 88194 1 0 -22 0 5856 340 vmpfw D qi- 0:01.34 emacs proxy. : :Any attempt to access emacs on the client system would result in a type of :hang for that process. Here is a 'cat /usr/local/bin/emacs /dev/null': : :2371 90317 1 3 -18 0 2688 pgtblk D p4- 0:00.02 cat /usr/loc : :To "fix" this I went to the NFS server and 'cp emacs emacs.new;rm emacs;mv emacs.new :emacs'. In essence forcing a new FH. The old procs still stick arround. : :This leads me to believe the problem is entirely on the local system (ie, :the kernel isn't asking for pages from the NFS server for that FH) : :Any ideas what could be corrupting the local cache (I am assuming that is the :problem) like this. Nothing of note in the dmesg. : :-- :David Cross | email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
On Thu, Feb 17, 2000 at 05:19:21PM -0500, Steve Ames wrote: Just read this article: http://www.zdnet.com/zdnn/stories/news/0,4586,2440002,00.html Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? FreeBSD runs very well on the Alpha, which is a 64 bit chip. There is plenty of 'vapor silicon' (as opposed to vaporware) out there, but until 64 bit chips can be bought readily in the PC world the Alpha port is the 64 bit flagship. -- Wilko Bulte Arnhem, The Netherlands http://www.tcja.nl The FreeBSD Project: http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: stuck NFS procs (LONG)
Ok... we'll start with the process table...
monica# ps axl | grep D
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
0 0 0 0 -18 0 00 sched DLs ??0:00.81 (swapper)
0 2 0 0 -18 0 00 psleep DL??1:10.93 (pagedaemon
0 3 0 91 18 0 00 psleep DL??0:26.62 (vmdaemon)
0 4 0 0 18 0 00 syncer DL??1:51.82 (syncer)
17727 74079 1 0 -22 0 5952 340 vmpfw D p4- 0:01.53 emacs websrv
17727 74586 1 0 -22 0 5952 340 vmpfw D p4- 0:01.55 emacs websrv
33639 88342 1 0 -22 0 5856 340 vmpfw D p4- 0:01.27 emacs proxy.
2371 90317 1 3 -18 0 2688 pgtblk D p4- 0:00.02 cat /usr/loc
2646 83637 1 0 -22 0 6256 528 vmpfw D p9- 0:03.56 emacs
2646 85055 1 0 -22 0 6344 528 vmpfw D p9- 0:03.00 emacs
2937 89546 1 0 -22 0 5576 340 vmpfw D pa0:00.55 emacs /usr/t
2575 75559 1 0 -22 0 5652 340 vmpfw D pf- 0:00.99 emacs simple
2575 78298 1 0 -22 0 5576 340 vmpfw D pj- 0:00.97 emacs watchf
32837 85464 1 0 -22 0 6264 528 vmpfw D pj- 0:02.81 emacs proj2.
32837 87204 1 0 -22 0 6264 528 vmpfw D pj- 0:03.75 emacs proj2.
17727 90346 1 2 -22 0 5940 344 vmpfw D pk- 0:01.23 emacs comm.c
2575 76313 1 0 -22 0 5656 340 vmpfw D pl- 0:01.54 emacs show_p
33355 84406 1 3 -22 0 7136 528 vmpfw D pl- 0:04.54 emacs osshel
33355 85094 1 0 -22 0 7184 528 vmpfw D pl- 0:04.52 emacs
17727 9 1 0 -22 0 5940 340 vmpfw D pl- 0:01.17 emacs comm.c
0 64921 63848 0 10 0 476 292 ppwait D pt0:00.07 -su (csh)
2551 75473 1 0 -22 0 7284 524 vmpfw D q4- 0:05.27 emacs tftp_s
2023 77402 1 0 -22 0 5672 340 vmpfw D q8- 0:00.71 emacs index.
37080 7 1 0 -22 0 6208 524 vmpfw D q8- 0:02.61 emacs bogosj
2440 86790 1 0 -22 0 7176 524 vmpfw D q9- 0:05.37 emacs bardet
2440 88149 1 1 -22 0 7244 524 vmpfw D q9- 0:04.91 emacs bardet
17727 89837 1 1 -22 0 5940 340 vmpfw D qd- 0:01.13 emacs comm.c
33639 88194 1 0 -22 0 5856 340 vmpfw D qi- 0:01.34 emacs proxy.
And we'll move on to some backtraces...
(kgdb) proc 74079
(kgdb) back
#0 mi_switch () at ../../kern/kern_synch.c:825
#1 0xc0131781 in tsleep (ident=0xc054b220, priority=0,
wmesg=0xc0208bc2 "vmpfw", timo=0) at ../../kern/kern_synch.c:443
#2 0xc01cfa3f in vm_fault (map=0xca8028c0, vaddr=136036352,
fault_type=3 '\003', fault_flags=8) at ../../vm/vm_fault.c:308
#3 0xc01ea17a in trap_pfault (frame=0xcac7ffbc, usermode=1, eva=136036368)
at ../../i386/i386/trap.c:816
#4 0xc01e9cca in trap (frame={tf_es = 136249383, tf_ds = -1078001625,
tf_edi = 400, tf_esi = 10, tf_ebp = -1078114780, tf_isp = -892862492,
tf_ebx = -1078110248, tf_edx = 136036332, tf_ecx = 137580544,
tf_eax = 1210023680, tf_trapno = 12, tf_err = 6, tf_eip = 134831395,
tf_cs = 31, tf_eflags = 66195, tf_esp = -1078114788, tf_ss = 39})
at ../../i386/i386/trap.c:358
(kgdb) proc 74586
(kgdb) back
#0 mi_switch () at ../../kern/kern_synch.c:825
#1 0xc0131781 in tsleep (ident=0xc054b220, priority=0,
wmesg=0xc0208bc2 "vmpfw", timo=0) at ../../kern/kern_synch.c:443
#2 0xc01cfa3f in vm_fault (map=0xca6262c0, vaddr=136036352,
fault_type=3 '\003', fault_flags=8) at ../../vm/vm_fault.c:308
#3 0xc01ea17a in trap_pfault (frame=0xcac58fbc, usermode=1, eva=136036368)
at ../../i386/i386/trap.c:816
#4 0xc01e9cca in trap (frame={tf_es = 39, tf_ds = 39, tf_edi = 2320,
tf_esi = 58, tf_ebp = -1078114780, tf_isp = -893022236,
tf_ebx = -1078108328, tf_edx = 136036332, tf_ecx = 137580544,
tf_eax = 1210023680, tf_trapno = 12, tf_err = 6, tf_eip = 134831395,
tf_cs = 31, tf_eflags = 66195, tf_esp = -1078114788, tf_ss = 39})
at ../../i386/i386/trap.c:358
(kgdb) proc 88342
(kgdb) back
#0 mi_switch () at ../../kern/kern_synch.c:825
#1 0xc0131781 in tsleep (ident=0xc054b220, priority=0,
wmesg=0xc0208bc2 "vmpfw", timo=0) at ../../kern/kern_synch.c:443
#2 0xc01cfa3f in vm_fault (map=0xca801240, vaddr=136036352,
fault_type=3 '\003', fault_flags=8) at ../../vm/vm_fault.c:308
#3 0xc01ea17a in trap_pfault (frame=0xca973fbc, usermode=1, eva=136036368)
at ../../i386/i386/trap.c:816
#4 0xc01e9cca in trap (frame={tf_es = 39, tf_ds = 39, tf_edi = 0, tf_esi = 0,
tf_ebp = -1078114664, tf_isp = -896057372, tf_ebx = -1078110532,
tf_edx = 136036332, tf_ecx = -1078110532, tf_eax = 1210023680,
tf_trapno = 12, tf_err = 6, tf_eip = 134831395, tf_cs = 31,
tf_eflags = 66195, tf_esp = -1078114672, tf_ss = 39})
at ../../i386/i386/trap.c:358
(this is the cat(1))
(kgdb) proc 90317
(kgdb) back
#0 mi_switch () at ../../kern/kern_synch.c:825
