> are you trying to trim a really large section at once? i think
> that's what i see:
>> [ - root] 3> date; ./trim /dev/rwd1d 4 2; date
That means "first six bytes contain 4, LE; second two bytes contain 2,
LE". I thought that in turn meant "2 sectors at offset 4". Apparently
it actually
are you trying to trim a really large section at once? i
think that's what i see:
> [ - root] 3> date; ./trim /dev/rwd1d 4 2; date
at least in my experience, the problem is that most devices
take a while to handle a TRIM request, longer than the 30s
timeout typically used.
this is why
On Sat, 10 Dec 2022, Mouse wrote:
OK, so any requests >4K will have to be packaged into further range
requests [...]
This isn't right. Bytes 7 & 8 of a TRIM range request form a
counter. So, a counter of 1 = (1 x max_dsm_blocks); 2 = (2 x
max_dsm_blocks) up to 0x counts.
So is
On Mon, Dec 12, 2022 at 23:31:06 +0300, Valery Ushakov wrote:
> > > With KDTRACE_HOOKS enabled (modulo clockintr hack) and the serial
> > > console (for debugging) I see the system stuck on console output when
> > > rc runs. It gets unstuck on a com interrupt (e.g. pressing a key).
> > >
> > >
On Mon, Dec 12, 2022 at 20:12:57 +, Taylor R Campbell wrote:
> Annoying... We really shouldn't abuse function prototypes like this:
> according to the prototype, what I did with intr_kdtrace_wrapper is
> correct.
Right, we decieved the compiler and the compiler was like, ok,
boomer...
> I
> Date: Sat, 10 Dec 2022 02:42:05 +0300
> From: Valery Ushakov
>
> So the culprit is KDTRACE_HOOKS in sys/arch/x86/x86/intr.c
>
> revision 1.163
> date: 2022-10-29 16:59:04 +0300; author: riastradh; state: Exp; lines:
> +38 -2; commitid: w28zVvYhMCIOsCZD;
> x86: Add dtrace probes for
On Mon, Dec 12, 2022 at 11:53:56PM +1100, matthew green wrote:
> maybe port that tool back, it's also supposed to match the
> linux command of the same name. it's not in netbsd-9, but
> last i tried, the interfaces the -current tool uses are
> available in -9 kernels.
The trim/discard
Sorry if this is the wrong list to send to but I think there may be a kernel bug
using textcons via iLO.
While it partially works, shift/shift lock key and sometimes space bar does
not seem to work properly.
I tested with Linux and did not see the same issue and I couldn't find any
settings
c...@sdf.org ("Stephen M. Jones") writes:
>While it partially works, shift/shift lock key and sometimes space bar =
>does
>not seem to work properly.
Can you be specific in how it does not work properly?
>[ 11434.0227330] ukbd0 at uhidev0
>[ 11434.4428808] ums0 at uhidev1: 3 buttons
>login:
