mpt Serious performance issues

? Regards, Stephan

Re: mpt Serious performance issues

that appers to be actively maintained. Best Regards, Stephan

Re: mpt Serious performance issues

tells about "tagged queueing"... Regards, Stephan 2010/11/29 Manuel Bouyer : > On Mon, Nov 29, 2010 at 09:05:16AM +0100, Stephan wrote: >> Hi, >> >> this is the reading result with 64k blocks after rebooting: >> >> >> # dd if=myfile of=/dev/null

Re: mpt Serious performance issues

I found a PR on this topic: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=30531 As described the Linux driver (and from my testing I can tell the FreeBSD driver also) does something differently than the NetBSD driver. I could do the testing if anyone has a hint on how to correct that is

Re: mpt Serious performance issues

if (xm->xm_mode & PERIPH_CAP_TQING) mpt->mpt_tag_enable |= (1 << xm->xm_target); else mpt->mpt_tag_enable &= ~(1 << xm->xm_target); What is going on here? Does the struct scsipi_xfer_mode *xm come from the scsipi layer so it tells the driver what to do? Regards, Stephan

Re: mpt Serious performance issues

capabilities a given device has? Regards, Stephan

Re: mpt Serious performance issues

OK, i got that. Regarding the mpt driver issue, is there a change to see if the driver operates in tagged queueing mode?

Re: mpt Serious performance issues

The mpt driver prints the following: mpt0 at pci3 dev 1 function 0: Symbios Logic 53c1020/53c1030 ioapic1: int4 1a9a8 f00 mpt0: interrupting at ioapic1 pin 4, event channel 3 scsibus0 at mpt0: 16 targets, 8 luns per target The Raid-Set appears as: sd0 at scsibus0 target 0 lun 0: disk fixed

Re: mpt Serious performance issues

I found another hint regarding slow mpt performance which was discussed for FreeBSD: === Would you be able to take a scsi bus trace to see what the negotiated speed over the bus? Also would you able to see when the driver loads if the PPR(Parallel Protocal Request) and WDTR(Wide da

Re: mpt Serious performance issues

/mpi.c?rev=1.165;content-type=text%2Fplain ). How would this be implemented in NetBSD? As a hack for testing, does anybody see a chance to hard-code this bit-setting into the driver? Regards, Stephan

Re: mpt Serious performance issues

"DEBUG: Successfully read raid page 0"); mpt_prt(mpt, "DEBUG: Volume ID: %d", mpt->mpt_raid_page0.VolumeID); mpt_prt(mpt, "DEBUG: Write Cache: %x", mpt->mpt_raid_page0.VolumeSettings.Settings & MPI_RAIDVOL0_SETTING_WRITE_CACHING_ENABLE); } == Just for clarification: What does IOC and SPI stand for? Regards, Stephan

Re: mpt Serious performance issues

It seems that if one waits a while after writing some data the read speed isn´t that bad. I do a find / -exec cat {} \; > /dev/null & and monitor the read speed with "sysstat vm". It is around 60 - 70 MB/s. This strengthens the suspicion that write caching isn´t working.

Re: mpt Serious performance issues

Now this is REALLY strange. I was wondering about why the read speed is sometimes high (~70MB/s) and sometimes very slow (~2MB/s). So I repeated the test utilizing find / -exec cat {} \; > /dev/null & to read everything from the filesystem while watching the physical disks with my eyes and the th

Re: mpt Serious performance issues

I do believe that this is a general issue since i have at least 5 very different servers with these mpt chips (not only 1030) that all did behave the same. My understanding for now is that -there is no issue with the settings between the scsipi layer and the virtual disk (TQ, WIDE, SYNC, etc.) -ev

FIXED: mpt Serious performance issues

Have a look at these values: find / -exec cat {} \; > /dev/null Disks: fd0 cd0 sd0 md0 seeks xfers 1085 bytes 68M %busy 92.4 bsddev# dd if=/dev/zero of=myfile bs=4096 count=10 10+0 records in

Re: FIXED: mpt Serious performance issues

sfers, tagged queueing This makes nothing faster but leads to ugly messages on writing: sd0(mpt0:0:0:0): adapter resource shortage sd0(mpt0:0:0:0): adapter resource shortage sd0(mpt0:0:0:0): adapter resource shortage sd0(mpt0:0:0:0): adapter resource shortage sd0(mpt0:0:0:0): adapter resource shortage sd0(mpt0:0:0:0): adapter resource shortage Regards, Stephan

Re: FIXED: mpt Serious performance issues

> Reset it to a known state. Okay. > No, but it's just wrong to apply the modes computed for the > virtual disk, to a physical disk. When the controller operates in RAID mode, is target page 0 still the disk page or the page for the RAID volume? I think that´s what Eduardo said. If it´s for the

Re: FIXED: mpt Serious performance issues

> > which behavior ? The behavior of resetting all target pages to 0. > >> >> >> > both x86 I guess, and both with the BIOS enabled. >> >> Both x86. Did you mean the mainboard BIOS or the MPT BIOS? > > the MPT BIOS Yes, it is enabled. > >> >> >> > for FC, tagged queuing should also work AFAIK.

Re: identifying I/O pigs

Hi I´ve never seen I/O accounting on a process basis on NetBSD. Though, FreeBSD offers this (top -m io). Regards, Stephan 2012/2/7 Emmanuel Dreyfus : > Hi > > As I undertand, when we see a NetBSD box on its knees because of high > disk I/O, we have no way to find the offending

vnode_to_path()

ction. */ else if (!(error = vnode_to_path(dp, MAXPATHLEN, p->p_textvp, l, p))) data->ed_pack.ep_path = dp; #endif I don´t understand the issue from the short description. Can someone explain what is exatly wrong? Regards, Stephan

Re: vnode_to_path()

, Stephan

Adding a .c-file to the kernel

Hi I want to add a new .c-file to the kernel source under sys/kern. What´s the right way to make the build system aware so it we be compiled into a new kernel image? I´m also unsure about the name. The code implements an IPC mechanism. I guess uipc_ is a good prefix, though I don´t know what 'u'

syscall related developer documentation

Hi I´m reffering to this documentation: http://www.netbsd.org/docs/internals/en/chap-processes.html#syscall_howto I do think that some points have changed with current versions of NetBSD (7, current). For example the format of syscalls.master and the argument handling. Could someone familiar ch

Re: Very slow transfers to/from micro SD card on a RPi B+

50, 100.000 MHz > > > > On Tue, 4 Aug 2015, Stephan wrote: > > These are my numbers on a class 10 Sony-SD-card when extracting pkgsrc.tar. >> >> tty ld0 CPU >> tin tout KB/t t/s MB/s us ni sy in id >>1 130 27.20 83 2.20

Re: Very slow transfers to/from micro SD card on a RPi B+

Makes no difference - there is almost no disk activity even with flushing enabled. Am 17.08.2015 20:13 schrieb "Martin Husemann" : > On Mon, Aug 17, 2015 at 06:08:32PM +, Stephan wrote: > > I have just rebooted with WAPBL enabled. Some quick notes: > > -Creating

Re: Very slow transfers to/from micro SD card on a RPi B+

2015-08-17 21:30 GMT+02:00 Michael van Elst : > stephan...@googlemail.com (Stephan) writes: > > >I have just rebooted with WAPBL enabled. Some quick notes: > > >-Sequential write speed is a little lower, around 5,4 MB/s. > > > WAPBL is rather slow on SD cards because

Re: Very slow transfers to/from micro SD card on a RPi B+

Sorry, I meant objcopy (it was already too late yesterday). I need a kernel.img file for the boot partition on the Pi. Jared said that needs to be extracted from the ELF kernel resulting from a regular build. 2015-08-18 12:55 GMT+02:00 Nick Hudson : > On 08/17/15 19:08, Stephan wrote: >

Re: Very slow transfers to/from micro SD card on a RPi B+

2015-08-18 13:06 GMT+02:00 J. Hannken-Illjes : > On 18 Aug 2015, at 12:44, Stephan wrote: > > > 2015-08-17 21:30 GMT+02:00 Michael van Elst : > > stephan...@googlemail.com (Stephan) writes: > > > > >I have just rebooted with WAPBL enabled. Some quick notes: >

Re: Very slow transfers to/from micro SD card on a RPi B+

2015-08-18 13:06 GMT+02:00 J. Hannken-Illjes : > On 18 Aug 2015, at 12:44, Stephan wrote: > > > 2015-08-17 21:30 GMT+02:00 Michael van Elst : > > stephan...@googlemail.com (Stephan) writes: > > > > >I have just rebooted with WAPBL enabled. Some quick notes: >

Re: Very slow transfers to/from micro SD card on a RPi B+

noying shortcomings. FreeBSD received dynamic memory allocation for DIRHASH which might be even better. (re-sending this as my editor intermittently distributes HTML mails) > > On Tue, Aug 18, 2015 at 04:19:57PM +, Michael van Elst wrote: >> stephan...@googlemail.co

Re: Very slow transfers to/from micro SD card on a RPi B+

(&tv_start, NULL); int fd = open(filename, O_CREAT); gettimeofday(&tv_finish, NULL); close(fd); duration = (tv_finish.tv_sec * 100 + tv_finish.tv_usec) - (tv_start.tv_sec * 100 + tv_start.tv_usec); printf("Duration: %lu\n", duration); } return 0; }

Understanding SPL(9)

Hi! I´m trying to understand interrupt priority levels using the example of x86. From what I´ve seen so far I´d say that all spl*() functions end up in either splraise() or spllower() from sys/arch/i386/i386/spl.S. What these functions actually do is not clear to me. For example, splraise() starts

Re: Understanding SPL(9)

2015-08-31 14:49 GMT+02:00 Manuel Bouyer : > On Mon, Aug 31, 2015 at 01:06:53PM +0200, Stephan wrote: >> Hi! >> >> I惴 trying to understand interrupt priority levels using the example >> of x86. From what I扉e seen so far I悲 say that all spl*() functions >> end up

Re: New sysctl entry: proc.PID.realpath

Wasn´t this the same as with RPATH and the name cache? 2015-09-07 9:23 GMT+02:00 Martin Husemann : > On Mon, Sep 07, 2015 at 03:50:21AM +0200, Kamil Rytarowski wrote: >> + error = vnode_to_path(path, MAXPATHLEN,vp, l, p); > > Two nits: > > 1) vnode_to_path(9) is undocumented > 2) it only wor

RPI2: Mutex related KASSERT when entering ddb(4)

rstand what this all is. I hope someone can fix this. Regards, Stephan

Re: RPI2: Mutex related KASSERT when entering ddb(4)

Hi Was that understandable? I can also provide a photo of the screen showing the whole stack and panic message, if required. Though I think it´s reproducible easily. 2015-09-22 9:01 GMT+02:00 Stephan : > Hi > > I´m running a pretty recent image of 7.0_RC3 on my RPI2. When I hit > Str

Re: RPI2: Mutex related KASSERT when entering ddb(4)

Hmm, I grabbed a recent HEAD kernel from nyftp.netbsd.org, but I saw the same issue. I may have to build my own kernel to be sure the change to usbdi.c is present. Does it work for you? 2015-09-26 16:00 GMT+02:00 Nick Hudson : > On 09/22/15 08:01, Stephan wrote: >> >> Hi >

Re: RPI2: Mutex related KASSERT when entering ddb(4)

Got the trick: The device boots "kernel7.img", not "kernel.img". Once I replaced that, it worked like expected. Can/should that be pulled up into -7? Thanks! 2015-10-04 12:55 GMT+02:00 Nick Hudson : > On 10/02/15 12:30, Stephan wrote: >> >> Hmm,

How to destroy a condvar(9) with waiters?

bject from the global list (nobody can find it afterwards) -release the interlock -destroy the interlock Thanks and regards, Stephan

Re: How to destroy a condvar(9) with waiters?

Thanks for your explanation. There are 2 condvars for the object - as far as I understand should one refcount be enough to make sure there are no waiters left on both, correct? 2015-12-28 15:33 GMT+01:00 Taylor R Campbell : >Date: Mon, 28 Dec 2015 14:35:14 +0100 >From: S

Re: How to destroy a condvar(9) with waiters?

rt->kp_waiters--; if ((port->kp_state == kp_deleted) && (port->waiters == 0)) { /* port has been logically destroyed, and we are the last waiter */ kport_delete_physical(port); return ENOENT; } Can this work? 2015-12-29 7:29 GMT+01:00 Stephan : > Thanks for your explanation. There

Re: How to destroy a condvar(9) with waiters?

> The destroyer would need the same logic to handle the case where there are no > waiters. Sorry, I should have been clearer. The (virtual) destroyer routine checks for that condition: if (port->kp_waiters > 0) { port->kp_state = kp_deleted; cv_broadcast(&port->kp_rdcv); cv_broadcast(&port

files.kern not included in release source?

Hi folks, to me it looks like files.kern in sys/kern is not included in the source tarballs of stable releases (e.g. netbsd-7). It is only visible in CVS under the MAIN tag. I´d like to continue some development based on the stable-7 source, so I would expect files.kern to be there in order to in

Re: RPI2: Mutex related KASSERT when entering ddb(4)

Can you pullup the polling-related corrections to usbdi.c to netbsd-7, so ddb(4) will work in the next bugfix release? Thanks and regards, Stephan 2015-10-04 12:55 GMT+02:00 Nick Hudson : > On 10/02/15 12:30, Stephan wrote: >> >> Hmm, I grabbed a recent HEAD kernel from nyftp.ne

Re: Very slow transfers to/from micro SD card on a RPi B+

00 18 1.114 0 0 0 0 100 0 45 0.0000 0.000 0 0 0 1 99 0 44 0.0000 0.000 0 0 0 0 100 There is even one second in the process without a single xfer. Can this be caused by the SD card itself, or may there be something improvable in the kernel? 2015-08-25 15:05 GM

Re: Very slow transfers to/from micro SD card on a RPi B+

owait+0x34 0xad86dcb4: bread+0x3c 0xad86dd64: ffs_read+0x398 0xad86dd94: VOP_READ+0x48 0xad86de24: ufs_readdir+0xe0 0xad86de64: VOP_READDIR+0x58 0xad86dedc: vn_readdir+0xcc 0xad86df14: sys___getdents30+0x80 0xad86df84: syscall+0x88 0xad86dfac: swi_handler+0x8c Any ideas? 2016-01-04 16:59 GMT+01:

Re: How to identify specific wait-state for a "DE" process?

> # crash > Crash version 7.99.25, image version 7.99.25. > Output from a running system is unreliable. > crash> trace/t 0t455 > trace: pid 455 lid 1 at 0xfe8002ff0ce0 > sleepq_block() at sleepq_block+0xa2 > cv_wait() at cv_wait+0x116 > fd_close() at fd_close+0x39a > fd_free() at fd_free+0x178

Re: How to identify specific wait-state for a "DE" process?

> # crash > Crash version 7.99.25, image version 7.99.25. > Output from a running system is unreliable. > crash> trace/t 0t455 > trace: pid 455 lid 1 at 0xfe8002ff0ce0 > sleepq_block() at sleepq_block+0xa2 > cv_wait() at cv_wait+0x116 > fd_close() at fd_close+0x39a > fd_free() at fd_free+0x178

Re: How to identify specific wait-state for a "DE" process?

> the arguments are printed if they're available. it's just that > on amd64 (which i'm assuming Paul is using) doesn't give you > those since they're passed in registers and aren't stored or > kept anywhere. i386 shows them.. (or at least, their current > value on their stack location): > > crash

Re: Very slow transfers to/from micro SD card on a RPi B+

2016-01-04 17:26 GMT+01:00 Stephan : > There is another issue with the Pi which I recognized when /etc/daily > runs. The "find / -" jobs causes certain threads to hang > for a long time. That´s easily reproducable by issuing "find / > > /dev/null &". In th

Re: Corosync on NetBSD

ong with the code obove? Stephan

Re: Kernel panic codes

Hi! What platform are you using? Why don´t you get a kernel dump; have you configured a swap device at least the size of your RAM? Regards! Am 15. April 2012 14:57 schrieb Nat Sloss : > Hi. > > I have been working on a program that uses bluetooth sco sockets and I am > having frequent kernel pa

Re: Kernel based virtual machine

like SVM. Regards, Stephan

Re: Serious WAPL performance problems

2012/10/25 Edgar Fuß : > Now this is getting weird. I have retried the experiment with neither softdep > nor log, i.e. with a plain old FFS, and that performs as well as or even > outperforms WAPL. > With both a 5.1_STABLE and a 6.0_RELEASE kernel, on a 16k fsbsize FFSv2, the > svn updates takes ar

Re: Serious WAPL performance problems

2012/10/25 Paul Goyette : > On Thu, 25 Oct 2012, Stephan wrote: > >> I always found FFS being slow when creating or deleting many files. >> For example, on 6.0 with FFSv2 and WAPBL it took 20 sec. to complete >> this: >> >> >> time seq 1 3 | xargs

Re: Back port of ixgbe driver to NetBSD 5

2012/10/25 Bob Lee : > The ixgbe driver supports 10Gb Intel 82598 and 82599 networking > devices. Tested with > an Intel E10G41AT2 card, connected two back to back, ping flood, netperf, and > configured > in Xen as PCI passthrough (running the same set of tests). > > - bob Could you pro

Re: Serious WAPL performance problems

> I just did this on my 6.99.14 system and it takes less than 1s: I also installed 6.99.14 in VirtualBox and it takes 40 seconds. Also I wonder which time(1) you use as thats more looking like FreeBSDs :)

Re: Serious WAPL performance problems

le doing this in a Linux DomU only > takes 1m and 48s (usign exactly the same Dom0). Exactly. Regards, Stephan

Re: Serious WAPL performance problems

Just for the log: LFS, EXT2 and TMPFS are all comparable slow when creating files. I created a small C program which counts from 1 to 3 internally and opens a corresponding file with O_CREAT. This takes half the time (9 secs.). The same program takes 0,09 secs. when just opening these files.

Re: Porting Corosync/Pacemaker - Help needed with gdb

tech-kern. I hope someone can help. Regards, Stephan 2012/12/5 Stephan > Some deeper insight: > > -8< > > Core was generated by `corosync'. > Program terminated with signal 11, Segmentation fault. > #0 0x7f7ff68078e9 in pthread_mutex_lock () fr

Re: Porting Corosync/Pacemaker - Help needed with gdb

rds, Stephan 2012/12/5 Manuel Bouyer > On Wed, Dec 05, 2012 at 12:32:52PM +0100, Stephan wrote: > > I suspect that there is something wrong with the stack. According to > pmap, > > and that seems to apply to all processes on NetBSD 6.0 amd64, the > corosync > > process h

Re: Porting Corosync/Pacemaker - Help needed with gdb

(gdb) x/2i 0x7f7ff68078e0 0x7f7ff68078e0 : mov%fs:0x0,%rax => 0x7f7ff68078e9 : mov0x10(%rax),%rdx --- I´m not sure what these instructions are supposed to do - i guess they should work on the parameter. Any idea how I can track this down? 2012/12/5 Manue

Re: Porting Corosync/Pacemaker - Help needed with gdb

It seems that the parameter (adress of conn_info->mutex) is passed through the %rdi register (though I thought that arguments are passed via stack): -8<- (gdb) frame 1 #1 0x7f7ff7002e14 in ipc_thread_active (conn=0x7f7ff7391000) at coroipcs.c:465 465 pthrea

Re: Porting Corosync/Pacemaker - Help needed with gdb

00\020\000\000\000\000\000\000\000"..., setup_bytes_read = 0, zcb_mapped_list_head = { next = 0x7f7ff7392120, prev = 0x7f7ff7392120}, sending_allowed_private_data = {0x0 }, poll_state = 1} Points to 0x7f7fefc0. 2012/12/7 Joerg Sonnenberger : > On Fri, Dec 07, 2012 at 12:29:37P

Re: wsdisplay framebuffer info

Hi, what about using proplib(3)s insted of a binary interface? Regards, Stephan 2013/1/22 Michael : > Hello, > > On Tue, 22 Jan 2013 21:03:00 +0100 > Martin Husemann wrote: > >> On Tue, Jan 22, 2013 at 02:26:32PM -0500, Michael wrote: >> > Anything I missed? Com

Testing 7.0 Beta: FFS still very slow when creating files

t doesn´t seem to be included. Regards, Stephan PS: My filesystems: # mount /dev/wd0a on / type ffs (local) /dev/wd0e on /a type ffs (log, local) /dev/wd0g on /c type ffs (local) kernfs on /kern type kernfs (local) ptyfs on /dev/pts type ptyfs (local) procfs on /proc type procfs (local) tmpfs

Re: Testing 7.0 Beta: FFS still very slow when creating files

-threaded. Regards, Stephan 2014-08-22 18:29 GMT+02:00 Taylor R Campbell : >Date: Fri, 22 Aug 2014 17:59:37 +0200 >From: Stephan > >Has anybody an idea on this or how to track this down? At the moment, >I can't even enter ddb using Strg+Alt+Esc keys for some reason.

Re: ixg(4) performances

What is your test setup? Do you have 2 identical boxes? Does it perform better e.g. on Linux or FreeBSD? If so, you could check how the config registers get set by that particular OS. 2014-08-28 9:26 GMT+02:00 Emmanuel Dreyfus : > On Tue, Aug 26, 2014 at 12:57:37PM +, Christos Zoulas wrote: >

Re: FFS: wrong superblock check ~> crash

Yes, you con configure that on a zpool: failmode YES wait | continue | panic This is relevant for SAN disks for instance, where you don´t necessarily want to crash the server when a disk becomes temporary unavailable. 2014-10-21 2:44 GMT+02:00 matthew green : > > Michael van E

boothowto(9) options with Raspberry Pi

the userconf(4) prompt. However, I wasn´t able to find out how to pass the corresponding boothowto(9) parameter (-c) to the kernel (I tried several variants in cmdline.txt). Is this approach possible and what is the way to do it? Thanks, Stephan

Problem with SIMPLEQ_INSERT_TAIL

don´t know. The compiler says: In file included from /home/stephan/src/sys/sys/siginfo.h:38, from /home/stephan/src/sys/sys/signal.h:112, from ./machine/frame.h:75, from ./x86/cpu.h:56, from ./machine/cpu.h:42, from

Re: Problem with SIMPLEQ_INSERT_TAIL

Okay, it was just a typo... hard to find by the compiler message. It works now, thanks alot! Am Mo., 22. Jan. 2024 um 12:37 Uhr schrieb J. Hannken-Illjes : > > > On 22. Jan 2024, at 11:52, Stephan wrote: > > > > Hello, > > > > I am working on the semaphore part

uvm_obj_wirepages() undocumented?

Hello, is uvm_obj_wirepages() (and uvm_obj_unwirepages()) as used in sys/kern/sysv_shm.c undocumented? I didn´t find it in any man page nor by searching the internet. Thanks, Stephan

Re: uvm_obj_wirepages() undocumented?

here: https://www.haiku-os.org/legacy-docs/bebook/TheKernelKit_Areas.html Areas can be locked into RAM. I am creating memory objects using uao_create() and I want to use uvm_obj_wirepages() to apply locking, if requested. Stephan Am Do., 13. Juni 2024 um 21:19 Uhr schrieb Jason Thorpe

Re: How to wait on cv_timedwait() correctly

ount of a semaphore somewhat below what the acquiring thread needs. This would be a regular wakeup without acquisition and requires adjusting the remaining timeout as well. Stephan

Re: How to wait on cv_timedwait() correctly

e up reporting error code 0 and the same amount of waiting threads :-/ The only thing left to mention is that I am working on a 2 years old snapshot of the source as syncing to upstream does not seem to be easy. Stephan

Re: How to wait on cv_timedwait() correctly

back to a free state. The whole code can be found here: https://github.com/stephanwib/src/blob/trunk/sys/kern/uipc_hsem.c This API is very close to what is found on BeOS/Haiku and is of course part of my effort to make Haiku software run on NetBSD. Stephan

How to wait on cv_timedwait() correctly

itbt_sig() suitable? Or should one track sleep and wakeup times and calculate a new timeout each time? Thanks, Stephan

uvm_unmap() vs. uvm_deallocate()

from address start to start + size. uvm_deallocate() is used e.g. in sysv_shm.c, in which case I would have expected uvm_unmap(). Thanks, Stephan

Re: How to wait on cv_timedwait() correctly

the waits as discussed here. The wakeup issue as it is now may also introduce erroneous behaviour to the semaphore API, but I am pretty sure this would be good on the current codebase. Stephan Am Di., 11. Feb. 2025 um 15:52 Uhr schrieb Taylor R Campbell : > > > Date: Tue, 11 Feb 2025

Re: How to wait on cv_timedwait() correctly

far so I don´t know what people think about that. Stephan

Re: alignment requirements for kmutex_t

Hello, maybe the attribute(3) man page is helpful to you too for these kinds of things. Stephan Am So., 30. März 2025 um 11:54 Uhr schrieb Beesdeckar : > > Hello, > I found that global variable of type kmutex_t is on many places defined > like: > kmutex_t variable_name __ca

Re: unkillable ps processes

Hi, you can invoke crash(8) and try to obtain a kernel stack trace. Stephan Am Do., 15. Mai 2025 um 09:45 Uhr schrieb Edgar Fuß : > > I have (on -10) processes (running ps, in case that matters) that are running, > consume 99% CPU time and are un-kill-able. > ktruss shows no

Re: unkillable ps processes

> Do you mean to issue the command stated in the EXAMPLES section of crash(8)? Yes, that always worked well for me. I remember using it by typing ps to obtain the address of the thread control structure, followed by "t/a " or "bt/a ".