Re: Attaching to an attribute

> Date: Fri, 8 Dec 2017 04:29:49 +0300 > From: Valery Ushakov > > Astonishingly, i386 and amd64 GENERIC do _not_ have > > wsmouse* at wsmousedev? > > wildcard attachment and instead use separate attachments for each > parent. I'm overcome with nostalgy, but this probably

Re: kernel condvars: how to use?

> Date: Thu, 7 Dec 2017 22:26:54 -0500 (EST) > From: Mouse > > DIAGNOSTIC and DEBUG are both on already. None of the LOCK* options > are, though - see Paul Goyette's response, below. My usual debug-all-the-things kernel configuration is: makeoptions DBG=-"-g"

Re: kernel condvars: how to use?

Omnibus reply here to some half-dozen of the replies; I'll try to get all the attributions right. First, a big thank you to everyone who replied. I was not expecting this many, nor this helpful, responses to something about NetBSD as old as 5.2! [me - all the double-quoted text here is mine] >>

Re: Attaching to an attribute

On Fri, 8 Dec 2017, Valery Ushakov wrote: This, however, still highlights a problem. How can a module device driver attach wsmouse as a child regardless of how the kernel is configured. The device driver module does all appropriate initialization, which includes config_init_component().

Re: Attaching to an attribute

On Fri, Dec 08, 2017 at 04:29:49 +0300, Valery Ushakov wrote: > On Thu, Dec 07, 2017 at 23:07:47 +0300, Valery Ushakov wrote: > > > However config(1) instead of providing single wildcard parent spec > > seems to instantiate parent specs for all parents it's seen that carry > > the attribute. >

Re: Attaching to an attribute

On Thu, Dec 07, 2017 at 23:07:47 +0300, Valery Ushakov wrote: > However config(1) instead of providing single wildcard parent spec > seems to instantiate parent specs for all parents it's seen that carry > the attribute. Bah, my emacs has too many buffers. Apparently I was looking at the kernel

Re: dtrace and ZFS update

In article <20171207211246.ga15...@spathi.chuq.com>, Chuck Silvers wrote: >hi folks, > >as taylor requested after the previous mail about this, >I've made a copy of the freebsd files that I started with >and put them in the netbsd source tree layout so that they >can easily be

Re: kernel condvars: how to use?

On Thu, 7 Dec 2017, Brian Buhrow wrote: 4. If you run into lock contention when debugging your code, pay careful attention to who holds the lock at the time of the panic. I found times when I was locking against myself in non-obvious manners. You might well find LOCKDEBUG to be your friend

Re: kernel condvars: how to use?

hello. I don't consider myself an expert with this stuff, but I've spent quite a bit of time converting kernel code from using spl()/splx() in 5.2 to using mutexes and convars with some success. Here are some notes that may be helpful in your work: 1. You must initialize mutexes, as

Re: kernel condvars: how to use?

> Date: Thu, 7 Dec 2017 18:24:22 -0500 (EST) > From: Mouse > > On reflection, I think I know why. Userland's syscall handler took the > mutex in preparation for cv_wait_sig(), the interrupt happens, my code > is called (verified with a printf), and it tries to take

Re: kernel condvars: how to use?

> Date: Thu, 7 Dec 2017 18:24:22 -0500 (EST) > From: Mouse > > db{0}> tr > breakpoint() at netbsd:breakpoint+0x5 > comintr() at netbsd:comintr+0x53a > Xintr_ioapic_edge7() at netbsd:Xintr_ioapic_edge7+0xeb > --- interrupt --- > x86_pause() at netbsd:x86_pause >

kernel condvars: how to use?

I'm trying to write some kernel code, interlocking between an interrupt (in my case, a callout()-called function) and a driver read() function. I'm using 5.2, so if this is because of bugs that have been fixed since then, that's useful information. (And anyone who isn't interested because I'm on

Re: dtrace and ZFS update

hi folks, as taylor requested after the previous mail about this, I've made a copy of the freebsd files that I started with and put them in the netbsd source tree layout so that they can easily be diffed against the merged tree. I've put several files in

Attaching to an attribute

Devices can be attached to an attribute, e.g. wsmouse* at wsmousedev? where potential parents declare to have that attribute, e.g. device ums: hid, wsmousedev and the autoconf code knows how to attach to the attribute only: static int cfparent_match(const device_t parent,

Re: getsockopt(2)

I wrote: >Does anyone know why we don't use the input 'optlen' parameter to the >getsockopt(2) syscall, we do write back to it on return. > >In ip_output() there is this, which suggests that someone had come >across this before. > >#if 0 /* defined(IPSEC) */ >case

Re: Oddities with my new machine: update

Recapping my issues, i had an hdaudio interrupt storm and serious issues with i915 graphics. I now run a 8.99.8 kernel but also tested an 8-release kernel. They both have the same behaviour for what its worth. Having a 7.1 kernel, userland and X gives rise to the problems I mentioned. X is

Re: avoid spinning processes when catching SEGV/BUS/FPE

In article <20171207074102.gc19...@mail.duskware.de>, Martin Husemann wrote: >On Wed, Dec 06, 2017 at 06:22:48PM -0500, Christos Zoulas wrote: >> This has also the unfortunate side effect that makes the problem >> undebuggable (aside from wasting CPU resources). The following

Re: avoid spinning processes when catching SEGV/BUS/FPE

>> This has also the unfortunate side effect that makes the problem >> undebuggable (aside from wasting CPU resources). The following >> patch fixes that. > Been there, tried to debug that - evil! > Could we auto-restore the signal handler when it returns? We would > seriously alter behaviour