Re: uhidev1 BMC Virtual Keyboard via HP iLO
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: abcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvwxyz
This looks fine.
>for constty I've tried a couple of different settings in /etc/ttys other =
>than wsvt25 thinking that
>may help (such as pc or vt100).
The value in /etc/ttys sets the TERM value which controls how programs
should interact with the terminal. This is already above anything
related to keyboard layout and key codes.
If you want to debug this, it is necessary to look at the lower levels,
the wskbd keymapping and even the USB stack. This is difficult if
this is the console, but you could configure the system to use
a serial console instead.
uhidev1 BMC Virtual Keyboard via HP iLO
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 other than language specific for keyboard that could resolve this. NetBSD 9.2 amd64 HP360 and HP380 iLO NetBSD/amd64 (Amnesiac) (constty) login: [ 11434.0127289] uhidev0 at uhub1 port 1 configuration 1 interface 0 [ 11434.0127289] uhidev0: BMC (0x3f0) Virtual Keyboard (0x7029), rev 1.10/0.02, addr 2, iclass 3/1 [ 11434.0227330] ukbd0 at uhidev0 [ 11434.4328771] wskbd1 at ukbd0 mux 1 [ 11434.4328771] uhidev1 at uhub1 port 1 configuration 1 interface 1 [ 11434.4328771] uhidev1: BMC (0x3f0) Virtual Keyboard (0x7029), rev 1.10/0.02, addr 2, iclass 3/1 [ 11434.4428808] ums0 at uhidev1: 3 buttons [ 11434.4428808] wsmouse1 at ums0 mux 0 login: abcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvwxyz for constty I've tried a couple of different settings in /etc/ttys other than wsvt25 thinking that may help (such as pc or vt100).
Re: ATA TRIM?
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 plumbing appeared in -7. -- David A. Holland dholl...@netbsd.org
Re: i386: 9.99.108 traps booting on VirtualBox
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). > > > > > > Seems to work fine with KDTRACE_HOOKS disabled. > > > > Do you mean that: > > > > - with KDTRACE_HOOKS enabled, clockintr hack applied, and console on > > serial, system gets stuck on console output until com interrupt > > Yes, I get some of the early output from rc and then the system > stalls. There's no further rc output and I don't get a login prompt > on the wscons. When I type a key into the serial console, the output > gets unstuck and I get the rest of the rc output and the login prompt > on wscons. PS: This is not on real hardware though, but under VirtualBox with serial connected to a TCP port. I have an ancient Dell laptop with a real on-board serial that I can probably try to verify this with if need be. -uwe
Re: i386: 9.99.108 traps booting on VirtualBox
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 think it would be reasonable to add an exception like you did for > now, maybe with an INTR_NOTRACE flag (perhaps someone can find a way > to phrase this positively) instead of a magic number, until we can > remove the abuse of calling convention for clockintr. As I said, it was just a quick kludge to avoid a bunch of files recompiled (and I didn't even get the number right...). > > 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). > > > > Seems to work fine with KDTRACE_HOOKS disabled. > > Do you mean that: > > - with KDTRACE_HOOKS enabled, clockintr hack applied, and console on > serial, system gets stuck on console output until com interrupt Yes, I get some of the early output from rc and then the system stalls. There's no further rc output and I don't get a login prompt on the wscons. When I type a key into the serial console, the output gets unstuck and I get the rest of the rc output and the login prompt on wscons. > - with KDTRACE_HOOKS disabled, and console on serial, system proceeds > without getting stuck on console output? Yes. -uwe
Re: i386: 9.99.108 traps booting on VirtualBox
> 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 interrupt handler entry and return.
>
> The problem is that clockintr has magic calling convention that
> intr_kdtrace_wrapper doesn't know about. As a quick hack I changed
> i8254_initclocks to pass a magic argument (that is ignored by
> clockintr anyway) and told the hook code to ignore such handlers:
>
> #ifdef KDTRACE_HOOKS
> if (arg != (void *)0x8042c10c) { /* clockintr is magic */
> ih->ih_fun = intr_kdtrace_wrapper;
> ih->ih_arg = ih;
> }
> #endif
>
> and that kernel doesn't crash.
Annoying... We really shouldn't abuse function prototypes like this:
according to the prototype, what I did with intr_kdtrace_wrapper is
correct. I think it would be reasonable to add an exception like you
did for now, maybe with an INTR_NOTRACE flag (perhaps someone can find
a way to phrase this positively) instead of a magic number, until we
can remove the abuse of calling convention for clockintr.
I searched for other interrupt handler functions with a similar
prototypes on x86, with `void *\*.*(clock|intr)frame'. I found only
three cases in tree:
- x86/isa/clock.c clockintr -- as you found
- x86/x86/lapic.c lapic_clockintr -- not a problem because this is
called directly by assembly stubs, not via struct intrhand::ih_func
- xen/xen/xen_clock.c xen_timer_handler -- not sure if this goes
through struct intrhand::ih_func on x86, but if it is, then on
!XENPV it might need to be adjusted similarly
> 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).
>
> Seems to work fine with KDTRACE_HOOKS disabled.
Do you mean that:
- with KDTRACE_HOOKS enabled, clockintr hack applied, and console on
serial, system gets stuck on console output until com interrupt
- with KDTRACE_HOOKS disabled, and console on serial, system proceeds
without getting stuck on console output?
Or do you mean that with KDTRACE_HOOKS disabled it avoids the crash,
but the system still gets stuck on console output?
Re: ATA TRIM?
> 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 means "2 * max_dsm_blocks at offset 4", but max_dsm_blocks is 8 for this device, so that's still only 8K. > 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. That's...odd. How can it be useful if it takes that long? Is the intent that it be useful only for very occasional "erase this whole filesystem" use, or what? I thought it was intended for routine filesystem use upon deleting files. > this is why blkdiscard(8) defaults to 32MiB chunks. I once did what I thought was trying to trim 16M, but my current understanding says that attempt would have been 128M. That didn't work any better. I just tried increasing the timeout to 30 (ie, five minutes) and trimming offset 0 size 8, which I now think for this device (with max_dsm_blocks 8) should mean 64 (interface) sectors, ie, 32k. It still timed out, with the same followup timeouts. Note the date output here; it took five minutes for the TRIM to time out, then thirty seconds for wd_flushcache. [ - root] 4> date; trim /dev/rwd1d 0 8; date Mon Dec 12 08:22:29 EST 2022 TRIM wd1: arg 00 00 00 00 00 00 08 00 Version 2040.283, max DSM blocks 8 TRIM wd1: calling exec piixide1:0:1: lost interrupt type: ata tc_bcount: 512 tc_skip: 0 TRIM wd1: returned 1 ATAIOCTRIM workd wd1: wd_flushcache: status=128 Mon Dec 12 08:27:59 EST 2022 [ - root] 5> dd if=/dev/rwd1d of=/dev/null count=8 piixide1:0:1: wait timed out wd1d: device timeout reading fsbn 0 (wd1 bn 0; cn 0 tn 0 sn 0), retrying wd1: soft error (corrected) 8+0 records in 8+0 records out 4096 bytes transferred in 0.005 secs (819200 bytes/sec) [ - root] 6> > maybe port that tool back, I'll try to have a look at it. I haven't been trying to match the -9 userland API, though, so I'm not sure how useful it will actually be. It may point me in a useful direction, though. > 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. I did bring over the 9.2 syssrc set, so I should be able to figure _something_ out. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: ATA TRIM?
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 max_dsm_blocks misnamed, or is it just being abused as a dsm_granularity value by TRIM, whereas other DSM commands do use it as a maximum? If the former, I'd like to rename it in my tree OK, I've now actually looked at what the spec[1] says instead of relying on my faulty recall of stuff I read on lwn.net years ago. So: A single range is 8 bytes: 6 bytes for LBA start + 2 for the count of sectors (logical, so 512 bytes). This makes 512 * 65535 bytes that can be trimmed by a single range. You can have 64 ranges in a 512-byte DSM packet. This makes 64 * 512 * 65535 bytes. max_dsm_blocks is the maximum no. of 512-byte DSM packets which the drive will accept. In your case, 8 blocks = 4K. Therefore your drive can trim, in a single DSM request, a maximum of 8 * 64 * 512 * 65535 = ~16 GB You clearly know a lot more about the relevant commands than I do, Clearly not :-( -RVP [1]: https://ata.wiki.kernel.org/index.php/Developer_Resources and https://web.archive.org/web/20200616054353if_/http://t13.org/Documents/UploadedDocuments/docs2017/di529r18-ATAATAPI_Command_Set_-_4.pdf
re: ATA TRIM?
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 blkdiscard(8) defaults to 32MiB chunks. 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. .mrg.
