Re: uhid spam: uhidev_intr: bad repid 33
On Tue, May 10, 2022 at 02:51:07PM +0100, Stuart Henderson wrote:
> On 2022/05/10 08:12, Anton Lindqvist wrote:
> > On Mon, May 09, 2022 at 05:44:29PM +0100, Stuart Henderson wrote:
> > > I have a USB combi keyboard/trackpad thing which is triggering "bad
> > > repid 33" frequently while attached (between a couple of times a minute,
> > > and once every few minutes). It does work but it's annoying.
> > >
> > > Presumably this is because it has non-contiguous report IDs?
> > > Anyone have an idea how to handle it?
> >
> > Could you send me the raw report descriptors:
> >
> > $ (set -e; i=0; while :; do doas usbhidctl -f /dev/uhid$i -R
> > >/tmp/uhid$i.raw; i=$((i + 1)); done)
> >
My guess here is that uhidev_maxrepid() does not observe all hid items
as it passes hid_none as the kind to hid_start_parse(). The userspace
equivalent of hid_start_parse() accepts a kind bitmask allowing
hid_get_item() to return items of varying kinds. For the kernel, we
could treat hid_none as a sentinel representing all possible hid kinds.
Does the following diff get rid of the bad repid output?
diff --git sys/dev/hid/hid.c sys/dev/hid/hid.c
index 1c4d5fa45e0..dd03d6d8943 100644
--- sys/dev/hid/hid.c
+++ sys/dev/hid/hid.c
@@ -229,7 +229,7 @@ hid_get_item(struct hid_data *s, struct hid_item *h)
* Only copy HID item, increment position and return
* if correct kind!
*/
- if (s->kind == c->kind) {
+ if (s->kind == hid_none || s->kind == c->kind) {
*h = *c;
DPRINTF("%u,%u,%u\n", h->loc.pos,
h->loc.size, h->loc.count);
Re: [External] : Re: 7.1-Current crash with NET_TASKQ 4 and veb interface
Hello, > > Yes. It is similar. > > I have read the whole mail thread and the final fix got commited. > But it looks incomplete, pf is still sleeping. > > Hrvoje, can you run the tests again that triggered the panics a > year ago? > > Sasha, I still think the way to go is mutex for pf locks. I don't > see a performance impact. you mean performance impact against 7.1? If it is the case, then I agree. > a single CPU anyway. And with sleeping locks you have to schedule > in the hot packet path. Our schedueler was never build for that. I don't think it is a problem of scheduler. I rather see it as problem of lock primitives, which can't keep consistency across a switch from CPU (a.k.a. sleep). > > At genua we started with mutex, made it fine grained, and converted > to rcu later. > I think the only reason why PF_LOCK() is a writer lock is overload tables. packet, which is about to update an overload table requires an exclusive PF_LOCK(). As soon as there will be a way to update overload table without an exclusive lock, then we can turn packets to PF_LOCK() readers. Also I somewhat disagree with idea 'network stack must never sleep'. The rw-lock adds places to network subsystem, where scheduler has a chance to give CPU to someone else. on the other hand let's stay real. if we want to keep at least part of the network stack running in parallel these days, then pf locks need to be turn to mutexes unless we want to hunt down all those SMR_READ sections and fix/workaround them to deal with sleep in underlying call-stack. I think either way (putting mutexes in vs. hunting down sleeping SMR section) is fine for me. My current plan is to move all those memory allocations in ioctl(2) path outside of PF_LOCK() scope. thanks and regards sashan
Re: 7.1-Current crash with NET_TASKQ 4 and veb interface
On Tue, May 10, 2022 at 09:37:12PM +0200, Hrvoje Popovski wrote: > On 9.5.2022. 22:04, Alexander Bluhm wrote: > > Can some veb or smr hacker explain how this is supposed to work? > > > > Sleeping in pf is also not ideal as it is in the hot path and slows > > down packets. But that is not easy to fix as we have to refactor > > the memory allocations before converting pf lock to a mutex. sashan@ > > is working on that. > > > Hi, > > isn't that similar or same panic that was talked about in "parallel > forwarding vs. bridges" mail thread on tech@ started by sashan@ > > https://www.mail-archive.com/tech@openbsd.org/msg64040.html Yes. It is similar. I have read the whole mail thread and the final fix got commited. But it looks incomplete, pf is still sleeping. Hrvoje, can you run the tests again that triggered the panics a year ago? Sasha, I still think the way to go is mutex for pf locks. I don't see a performance impact. Without it, we can run network only on a single CPU anyway. And with sleeping locks you have to schedule in the hot packet path. Our schedueler was never build for that. At genua we started with mutex, made it fine grained, and converted to rcu later. bluhm
Re: amdgpu not reliably resuming?
On Tue, May 10, 2022 at 09:08:04PM +1000, Jonathan Gray wrote: Hello Jonathan, >>> I've had a Ryzen machine with a (basic!) Polaris GPU for about a year. >>> Over that time nearly all of the GPU related bugs have disappeared >>> (thanks Jonathan et al.!), except for the fact that I don't seem to be >>> able to reliably suspend/resume from X. >> I thought it might be worth noting that, unfortunately, despite amdgpu and >> mesa updates this machine still can't reliably suspend or resume once X is >> doing something. [From the non-X terminal, suspend/resume works fine.] >> >> Since I guess this machine is now fairly standard hardware, I wonder if >> there's some obvious X or BIOS setting that I should be tweaking, but >> nothing I've tried seems to help so far! > I can't think of anything besides the tpm bios settings on some intel based > laptops a while ago. > > "AMDIF030" at acpi0 not configured is a gpio device without a driver. > Perhaps that state needs to be restored? > Though that appears on a x470 board I can resume and unhibernate on with a > vega10 card. Maybe! Would that device have some sort of interaction with X one way or another? Because it seems that I can reliably suspend/resume if xenodm is on the login page, but after I've logged in via xenodm, suspend rarely works and, if it does, resume almost certainly doesn't. As that suggest, I haven't got a clue where to start with this! Laurie
Re: [External] : Re: 7.1-Current crash with NET_TASKQ 4 and veb interface
Hello, On Tue, May 10, 2022 at 09:37:12PM +0200, Hrvoje Popovski wrote: > On 9.5.2022. 22:04, Alexander Bluhm wrote: > > Can some veb or smr hacker explain how this is supposed to work? > > > > Sleeping in pf is also not ideal as it is in the hot path and slows > > down packets. But that is not easy to fix as we have to refactor > > the memory allocations before converting pf lock to a mutex. sashan@ > > is working on that. > rw-lock in pf is indeed a next step. The first step is to move memory allocations done by ioctl(2) out of network path. same goes to copyin()/copyout(). I'm currently looking at art tables. I theory it should be possible to replace current radix tables with art tables. If I understand things right, this would also solve locking on update. > > Hi, > > isn't that similar or same panic that was talked about in "parallel > forwarding vs. bridges" mail thread on tech@ started by sashan@ > > https://www.mail-archive.com/tech@openbsd.org/msg64040.html > this is very similar to panics you've found. However this time packets sneak to sleep path via call to veb_span(). I agree the fix looks odd. May be another way around it would be to add a task to every veb switch. The task will dispatch packets to slow path. regards sashan
Re: 7.1-Current crash with NET_TASKQ 4 and veb interface
> On 10 May 2022, at 22:37, Hrvoje Popovski wrote: > > On 9.5.2022. 22:04, Alexander Bluhm wrote: >> Can some veb or smr hacker explain how this is supposed to work? >> >> Sleeping in pf is also not ideal as it is in the hot path and slows >> down packets. But that is not easy to fix as we have to refactor >> the memory allocations before converting pf lock to a mutex. sashan@ >> is working on that. > > > Hi, > > isn't that similar or same panic that was talked about in "parallel > forwarding vs. bridges" mail thread on tech@ started by sashan@ > > https://www.mail-archive.com/tech@openbsd.org/msg64040.html > > Yes, both panics invocated by sleep attempt within SMR section.
Re: 7.1-Current crash with NET_TASKQ 4 and veb interface
On 9.5.2022. 22:04, Alexander Bluhm wrote: > Can some veb or smr hacker explain how this is supposed to work? > > Sleeping in pf is also not ideal as it is in the hot path and slows > down packets. But that is not easy to fix as we have to refactor > the memory allocations before converting pf lock to a mutex. sashan@ > is working on that. Hi, isn't that similar or same panic that was talked about in "parallel forwarding vs. bridges" mail thread on tech@ started by sashan@ https://www.mail-archive.com/tech@openbsd.org/msg64040.html
Re: ktrace assert failure on OpenBSD 7.1
On 22-05-08 05:20:03, Visa Hankala wrote:
> On Sat, May 07, 2022 at 07:47:12PM +1000, Joel Sing wrote:
> > After upgrading an OpenBSD arm64 (pine64+ board) Go builder to 7.1, the
> > following has been triggered twice (once every couple of days):
> >
> > panic: kernel diagnostic assertion "kn->kn_kq == kq" failed: file
> > "/usr/src/sys/kern/kern_event.c", line 1811
> > Stopped at panic+0x160:cmp w21, #0x0
> > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> > 152330 84924 1001 0x3 0x4003 http.test
> > *427942 85055 1001 0x3 0x4001 net.test
> > 460437 53928 0 0x14000 0x2002 tztq
> > 197440 95098 0 0x14000 0x2000 softnet
> > db_enter() at panic+0x15c
> > panic() at __assert+0x24
> > panic() at knote_remove+0x2c4
> > knote_remove() at knote_fdclose+0x88
> > knote_fdclose() at fdrelease+0x94
> > fdrelease() at svc_handler+0x2d4
> > svc_handler() at do_el0_sync+0xa0
> >
> > This was stable with 7.0, hence seems to be a regression between 7.0 and 7.1
> > (presumably unlocking related).
>
> There is a race condition in knote_remove(). The function does not
> take into account that another thread might resize kq_knlist[] while
> knote_remove() clears a knote.
>
> I think the flaw has been present since r1.109 of kern_event.c when I
> made the subsystem allow sleeping inside event filters. I guess the
> recent unlockings now enable such timings that trigger the error.
>
> Joel, could you test the following patch?
>
> For a speedier trial, the bug's incidence rate can be increased by
> lowering the value of KQEXTENT in sys/sys/eventvar.h. Even a value
> as low as 1 should work (though one can ask if this will actually
> test the original issue).
Thanks - I recompiled with KQEXTENT = 8 and was able to reproduce
the problem in less than an hour. Applying the diff, the machine
has been up and running for nearly 48 hours without an issue.
Diff makes sense - ok jsing@
> Index: sys/kern/kern_event.c
> ===
> RCS file: src/sys/kern/kern_event.c,v
> retrieving revision 1.187
> diff -u -p -r1.187 kern_event.c
> --- sys/kern/kern_event.c 6 May 2022 13:12:16 - 1.187
> +++ sys/kern/kern_event.c 8 May 2022 04:31:21 -
> @@ -121,8 +121,8 @@ void knote_dequeue(struct knote *kn);
> int knote_acquire(struct knote *kn, struct klist *, int);
> void knote_release(struct knote *kn);
> void knote_activate(struct knote *kn);
> -void knote_remove(struct proc *p, struct kqueue *kq, struct knlist *list,
> - int purge);
> +void knote_remove(struct proc *p, struct kqueue *kq, struct knlist **plist,
> + int idx, int purge);
>
> void filt_kqdetach(struct knote *kn);
> int filt_kqueue(struct knote *kn, long hint);
> @@ -1563,10 +1563,10 @@ kqueue_purge(struct proc *p, struct kque
>
> mtx_enter(>kq_lock);
> for (i = 0; i < kq->kq_knlistsize; i++)
> - knote_remove(p, kq, >kq_knlist[i], 1);
> + knote_remove(p, kq, >kq_knlist, i, 1);
> if (kq->kq_knhashmask != 0) {
> for (i = 0; i < kq->kq_knhashmask + 1; i++)
> - knote_remove(p, kq, >kq_knhash[i], 1);
> + knote_remove(p, kq, >kq_knhash, i, 1);
> }
> mtx_leave(>kq_lock);
> }
> @@ -1789,13 +1789,15 @@ knote(struct klist *list, long hint)
> * remove all knotes from a specified knlist
> */
> void
> -knote_remove(struct proc *p, struct kqueue *kq, struct knlist *list, int
> purge)
> +knote_remove(struct proc *p, struct kqueue *kq, struct knlist **plist, int
> idx,
> +int purge)
> {
> struct knote *kn;
>
> MUTEX_ASSERT_LOCKED(>kq_lock);
>
> - while ((kn = SLIST_FIRST(list)) != NULL) {
> + /* Always fetch array pointer as another thread can resize kq_knlist. */
> + while ((kn = SLIST_FIRST(*plist + idx)) != NULL) {
> KASSERT(kn->kn_kq == kq);
>
> if (!purge) {
> @@ -1863,7 +1865,7 @@ knote_fdclose(struct proc *p, int fd)
> LIST_FOREACH(kq, >fd_kqlist, kq_next) {
> mtx_enter(>kq_lock);
> if (fd < kq->kq_knlistsize)
> - knote_remove(p, kq, >kq_knlist[fd], 0);
> + knote_remove(p, kq, >kq_knlist, fd, 0);
> mtx_leave(>kq_lock);
> }
> }
Re: uhid spam: uhidev_intr: bad repid 33
On 2022/05/10 08:12, Anton Lindqvist wrote: > On Mon, May 09, 2022 at 05:44:29PM +0100, Stuart Henderson wrote: > > I have a USB combi keyboard/trackpad thing which is triggering "bad > > repid 33" frequently while attached (between a couple of times a minute, > > and once every few minutes). It does work but it's annoying. > > > > Presumably this is because it has non-contiguous report IDs? > > Anyone have an idea how to handle it? > > Could you send me the raw report descriptors: > > $ (set -e; i=0; while :; do doas usbhidctl -f /dev/uhid$i -R > >/tmp/uhid$i.raw; i=$((i + 1)); done) > Attached. 0x05 0x01 0x09 0x02 0xa1 0x01 0x05 0x01 0x09 0x02 0xa1 0x02 0x85 0x1a 0x09 0x01 0xa1 0x00 0x05 0x09 0x19 0x01 0x29 0x05 0x95 0x05 0x75 0x01 0x15 0x00 0x25 0x01 0x81 0x02 0x75 0x03 0x95 0x01 0x81 0x01 0x05 0x01 0x09 0x30 0x09 0x31 0x95 0x02 0x75 0x10 0x16 0x01 0x80 0x26 0xff 0x7f 0x81 0x06 0xa1 0x02 0x85 0x12 0x09 0x48 0x95 0x01 0x75 0x02 0x15 0x00 0x25 0x01 0x35 0x01 0x45 0x10 0xb1 0x02 0x85 0x1a 0x09 0x38 0x35 0x00 0x45 0x00 0x95 0x01 0x75 0x10 0x16 0x01 0x80 0x26 0xff 0x7f 0x81 0x06 0xc0 0xa1 0x02 0x85 0x12 0x09 0x48 0x75 0x02 0x15 0x00 0x25 0x01 0x35 0x01 0x45 0x10 0xb1 0x02 0x35 0x00 0x45 0x00 0x75 0x04 0xb1 0x01 0x85 0x1a 0x05 0x0c 0x95 0x01 0x75 0x10 0x16 0x01 0x80 0x26 0xff 0x7f 0x0a 0x38 0x02 0x81 0x06 0xc0 0xc0 0xc0 0xc0 0x05 0x0c 0x09 0x01 0xa1 0x01 0x05 0x01 0x09 0x02 0xa1 0x02 0x85 0x1f 0x05 0x0c 0x0a 0x38 0x02 0x95 0x01 0x75 0x10 0x16 0x01 0x80 0x26 0xff 0x7f 0x81 0x06 0x85 0x17 0x06 0x00 0xff 0x0a 0x06 0xff 0x0a 0x0f 0xff 0x15 0x00 0x25 0x01 0x35 0x01 0x45 0x10 0x95 0x02 0x75 0x02 0xb1 0x02 0x0a 0x04 0xff 0x35 0x00 0x45 0x00 0x95 0x01 0x75 0x01 0xb1 0x02 0x75 0x03 0xb1 0x01 0xc0 0xc0 0x05 0x01 0x09 0x02 0xa1 0x01 0x05 0x01 0x09 0x02 0xa1 0x02 0x85 0x1a 0x09 0x01 0xa1 0x00 0x05 0x09 0x19 0x01 0x29 0x05 0x95 0x05 0x75 0x01 0x15 0x00 0x25 0x01 0x81 0x02 0x75 0x03 0x95 0x01 0x81 0x01 0x05 0x01 0x09 0x30 0x09 0x31 0x95 0x02 0x75 0x10 0x16 0x01 0x80 0x26 0xff 0x7f 0x81 0x06 0xa1 0x02 0x85 0x12 0x09 0x48 0x95 0x01 0x75 0x02 0x15 0x00 0x25 0x01 0x35 0x01 0x45 0x10 0xb1 0x02 0x85 0x1a 0x09 0x38 0x35 0x00 0x45 0x00 0x95 0x01 0x75 0x10 0x16 0x01 0x80 0x26 0xff 0x7f 0x81 0x06 0xc0 0xa1 0x02 0x85 0x12 0x09 0x48 0x75 0x02 0x15 0x00 0x25 0x01 0x35 0x01 0x45 0x10 0xb1 0x02 0x35 0x00 0x45 0x00 0x75 0x04 0xb1 0x01 0x85 0x1a 0x05 0x0c 0x95 0x01 0x75 0x10 0x16 0x01 0x80 0x26 0xff 0x7f 0x0a 0x38 0x02 0x81 0x06 0xc0 0xc0 0xc0 0xc0 0x05 0x0c 0x09 0x01 0xa1 0x01 0x05 0x01 0x09 0x02 0xa1 0x02 0x85 0x1f 0x05 0x0c 0x0a 0x38 0x02 0x95 0x01 0x75 0x10 0x16 0x01 0x80 0x26 0xff 0x7f 0x81 0x06 0x85 0x17 0x06 0x00 0xff 0x0a 0x06 0xff 0x0a 0x0f 0xff 0x15 0x00 0x25 0x01 0x35 0x01 0x45 0x10 0x95 0x02 0x75 0x02 0xb1 0x02 0x0a 0x04 0xff 0x35 0x00 0x45 0x00 0x95 0x01 0x75 0x01 0xb1 0x02 0x75 0x03 0xb1 0x01 0xc0 0xc0 0x05 0x0c 0x09 0x01 0xa1 0x01 0x85 0x20 0x06 0x00 0xff 0x15 0x00 0x26 0xff 0x00 0x75 0x08 0x95 0x12 0x0a 0x0a 0xfa 0xb1 0x02 0x85 0x21 0x06 0x00 0xff 0x15 0x00 0x25 0x01 0x75 0x01 0x95 0x10 0x1a 0x10 0xfa 0x2a 0x1f 0xfa 0x81 0x02 0x85 0x28 0x06 0x00 0xff 0x1a 0x10 0xfa 0x2a 0x1f 0xfa 0xb1 0x02 0x85 0x22 0x06 0x00 0xff 0x15 0x00 0x26 0xff 0x00 0x75 0x08 0x95 0x1a 0x0a 0x0a 0xfa 0xb1 0x02 0x85 0x23 0x06 0x00 0xff 0x0a 0x0a 0xfa 0xb1 0x02 0x85 0x24 0x06 0x00 0xff 0x95 0x1f 0x0a 0x0a 0xfa 0xb1 0x02 0x85 0x25 0x06 0x00 0xff 0x0a 0x0a 0xfa 0xb1 0x02 0x85 0x26 0x06 0x00 0xff 0x0a 0x0a 0xfa 0xb1 0x02 0x85 0x27 0x06 0x00 0xff 0x0a 0x0a 0xfa 0x81 0x02 0x85 0x14 0x06 0x00 0xff 0x15 0x00 0x25 0x03 0x75 0x02 0x95 0x01 0x0a 0x01 0xfe 0x81 0x02 0x75 0x06 0x81 0x01 0x85 0x04 0x06 0x00 0xff 0x15 0x00 0x25 0x03 0x75 0x02 0x95 0x01 0x0a 0x01 0xfe 0x81 0x02 0x75 0x06 0x81 0x01 0xc0 0x05 0x0c 0x09 0x01 0xa1 0x01 0x85 0x07 0x05 0x0c 0x19 0x00 0x2a 0xff 0x03 0x95 0x01 0x75 0x10 0x15 0x00 0x26 0xff 0x03 0x81 0x00 0x05 0x07 0x19 0x00 0x29 0xff 0x75 0x08 0x26 0xff 0x00 0x81 0x00 0x81 0x01 0x06 0x00 0xff 0x0a 0x03 0xfe 0x0a 0x04 0xfe 0x75 0x01 0x95 0x02 0x25 0x01 0x81 0x02 0x0a 0x05 0xff 0x95 0x01 0x75 0x05 0x25 0x1f 0x81 0x02 0x75 0x01 0x81 0x01 0x1a 0x01 0xfd 0x2a 0xff 0xfd 0x15 0x01 0x26 0xff 0x00 0x75 0x08 0x81 0x00 0x0a 0x02 0xff 0x26 0xff 0x00 0x15 0x00 0x81 0x02 0xc0 0x06 0xbc 0xff 0x09 0x88 0xa1 0x01 0x85 0x08 0x19 0x01 0x29 0xff 0x15 0x01 0x26 0xff 0x00 0x95 0x01 0x75 0x08 0x81 0x00 0xc0 0x05 0x01 0x09 0x80 0xa1 0x01 0x85 0x03 0x19 0x00 0x29 0xff 0x15 0x00 0x26 0xff 0x00 0x81 0x00 0xc0 0x05 0x0c 0x09 0x01 0xa1 0x01 0x85 0x20 0x06 0x00 0xff 0x15 0x00 0x26 0xff 0x00 0x75 0x08 0x95 0x12 0x0a 0x0a 0xfa 0xb1 0x02 0x85 0x21 0x06 0x00 0xff 0x15 0x00 0x25 0x01 0x75 0x01 0x95 0x10 0x1a 0x10 0xfa 0x2a 0x1f 0xfa 0x81 0x02 0x85 0x28 0x06 0x00 0xff 0x1a 0x10 0xfa 0x2a 0x1f 0xfa 0xb1 0x02 0x85 0x22 0x06 0x00 0xff 0x15 0x00 0x26 0xff 0x00 0x75 0x08 0x95 0x1a 0x0a 0x0a 0xfa 0xb1 0x02 0x85 0x23 0x06 0x00 0xff 0x0a 0x0a 0xfa 0xb1 0x02 0x85 0x24 0x06 0x00 0xff 0x95 0x1f 0x0a 0x0a 0xfa 0xb1 0x02 0x85
ucom(4) stopped working on armv7
Hi all,
I've been using a small CuBox-i armv6 machine to serve as serial
console server for my home router for years. It uses a uplcom(4) USB
to serial adapter for that connection. I don't use it frequently (the
home router has been very stable), but just found out that it stopped
working:
[weerd@cube] $ cu -l cuaU0 -s 115200
cu: open("/dev/cuaU0"): Input/output error
After that I see the following in dmesg:
ehci_sync_hc: tsleep() = 35
ehci_sync_hc: tsleep() = 35
ehci_sync_hc: tsleep() = 35
After that attempt.
I have quite a collection of uplcom(4), so I tried another with the
same result. Then I found an uchcom(4) in my stash. I'm not sure
that worked before (never tried it on the CuBox - it works on my amd64
system just fine), but that gives an error in dmesg:
uchcom0: cannot get version: IOERROR
or
uchcom0: cannot get version: TIMEOUT
and then the same:
ehci_sync_hc: tsleep() = 35
ehci_sync_hc: tsleep() = 35
ehci_sync_hc: tsleep() = 35
Then I also have a umcs(4) (also never before tried on the CuBox),
that doesn't work at all; when I plug it in I get:
uhub0: device problem, disabling port 1
I do occasionally upgrade the CuBox (not too frequently, as upgrades
take forever on these slow storage machines), and it seems this issue
was introduced after one of those upgrades. Last time it was working
(according to the serial console logs I keep) was 16 November 2021,
then a reboot on 20 December 2021 (after an upgrade) and it didn't
work anymore.
2021-11-16T18:12:39.884Z cube /bsd: OpenBSD 7.0-current (GENERIC) #80416: Wed
Nov 10 08:09:48 MST 2021
2021-12-20T18:28:41.825Z cube /bsd: OpenBSD 7.0-current (GENERIC) #2: Fri Dec
10 18:04:30 MST 2021
I went through all the commits from 10 November to 10 December,
weeding out commits to www, xenocara and commits that don't touch
files in sys/. Then I deleted anything related to networking, other
architectures and devices that aren't present on this machine (e.g.
stuff in pci/) - still left me with 77 commits to bisect through
(that, plus my filtering may have been wrong).
If anybody has a suggestion of what commit could cause this to try to
back out, I would appreciate hearing about it - the machine takes a
long long time to build a kernel, so any hints that can speed up
the process are very welcome.
Thanks,
Paul
U-Boot SPL 2019.01 (Apr 10 2019 - 00:26:35 +0200)
Trying to boot from MMC1
U-Boot 2019.01 (Apr 10 2019 - 00:26:35 +0200)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 51C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM: 2 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out: serial
Err: serial
Card did not respond to voltage select!
Net: FEC
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
36813 bytes read in 16 ms (2.2 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Disk usb0 not ready
Disk usb1 not ready
Disk usb2 not ready
Disk usb3 not ready
Scanning disks on mmc...
Card did not respond to voltage select!
MMC: no card present
MMC Device 2 not found
MMC Device 3 not found
Scanning disks on sata...
Disk sata0 not ready
Found 3 disks
112524 bytes read in 30 ms (3.6 MiB/s)
## Starting EFI application at 1200 ...
disks: sd0*
>> OpenBSD/armv7 BOOTARM 1.19
boot>
booting sd0a:/bsd: 4915296+743624+320472+590148 [273998+107+338224+300055]=0x0
OpenBSD/armv7 booting ...
arg0 0xc0a24334 arg1 0x0 arg2 0x8e448000
Allocating page tables
IRQ stack: p0x10a53000 v0xc0a53000
ABT stack: p0x10a54000 v0xc0a54000
UND stack: p0x10a55000 v0xc0a55000
SVC stack: p0x10a56000 v0xc0a56000
Creating L1 page table at 0x10a28000
Mapping kernel
Constructing L2 page tables
undefined page type 0x2 pa 0x1000 va 0x1000 pages 0x2000 attr 0x8
type 0x7 pa 0x1200 va 0x1000 pages 0x5ef4 attr 0x8
type 0x6 pa 0x17ef4000 va 0x17ef4000 pages 0x18 attr 0x8008
type 0x7 pa 0x17f0c000 va 0x17f0c000 pages 0x7653c attr 0x8
type 0x2 pa 0x8e448000 va 0x8e448000 pages 0xb attr 0x8
type 0x4 pa 0x8e453000 va 0x8e453000 pages 0x1 attr 0x8
type 0x2 pa 0x8e454000 va 0x8e451000 pages 0x100 attr 0x8
type 0x1 pa 0x8e554000 va 0x8e554000 pages 0x1c attr 0x8
type 0x6 pa 0x8e57 va 0x8e57 pages 0x1 attr 0x8008
type 0x0 pa 0x8e571000 va 0x8e56c000 pages 0x4 attr 0x8
type 0x6 pa 0x8e575000 va 0x8e575000 pages 0x1 attr 0x8008
type 0x0 pa 0x8e576000 va 0x8e576000 pages 0x2 attr 0x8
type 0x2 pa 0x8e578000 va 0x8e578000 pages 0x1a01 attr 0x8
type 0x5 pa 0x8ff79000 va 0x8ff79000 pages 0x1 attr 0x8008
type 0x2 pa 0x8ff7a000 va 0x8e578000 pages 0x86 attr 0x8
pmap [ using 912920 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All
Re: amdgpu not reliably resuming?
On Tue, May 10, 2022 at 08:16:28AM +0100, Laurence Tratt wrote: > On Sun, Jan 23, 2022 at 09:20:20AM +, Laurence Tratt wrote: > > > I've had a Ryzen machine with a (basic!) Polaris GPU for about a year. Over > > that time nearly all of the GPU related bugs have disappeared (thanks > > Jonathan et al.!), except for the fact that I don't seem to be able to > > reliably suspend/resume from X. > > I thought it might be worth noting that, unfortunately, despite amdgpu and > mesa updates this machine still can't reliably suspend or resume once X is > doing something. [From the non-X terminal, suspend/resume works fine.] > > Since I guess this machine is now fairly standard hardware, I wonder if > there's some obvious X or BIOS setting that I should be tweaking, but > nothing I've tried seems to help so far! I can't think of anything besides the tpm bios settings on some intel based laptops a while ago. "AMDIF030" at acpi0 not configured is a gpio device without a driver. Perhaps that state needs to be restored? Though that appears on a x470 board I can resume and unhibernate on with a vega10 card. > > In case it's useful here's today's dmesg, where when I tried to suspect the > display did (as expected) stop displaying anything, but the machine did > not stop running (e.g. the fans & lights didn't turn off): > > OpenBSD 7.1-current (GENERIC.MP) #509: Mon May 9 22:13:31 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 34211557376 (32626MB) > avail mem = 33157357568 (31621MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xcb9f7000 (72 entries) > bios0: vendor American Megatrends Inc. version "2423" date 08/09/2021 > bios0: ASUS ROG STRIX B550-E GAMING > acpi0 at bios0: ACPI 6.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT SSDT FIDT FPDT MCFG HPET IVRS VFCT BGRT > WPBT PCCT SSDT CRAT CDIT SSDT SSDT SSDT SSDT WSMT APIC SSDT SSDT > acpi0: wakeup devices GP12(S4) GP13(S4) XHC0(S4) GP30(S4) GP31(S4) X161(S4) > X162(S4) PTXH(S4) X1_1(S4) X1_2(S4) WIFI(S4) I225(S4) X163(S4) M2_2(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf000, bus 0-127 > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 9 5900X 12-Core Processor, 3700.48 MHz, 19-21-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully > associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully > associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 100MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: AMD Ryzen 9 5900X 12-Core Processor, 3700.01 MHz, 19-21-00 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully > associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully > associative > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: AMD Ryzen 9 5900X 12-Core Processor, 3700.00 MHz, 19-21-00 > cpu2: >
Re: amdgpu not reliably resuming?
On Sun, Jan 23, 2022 at 09:20:20AM +, Laurence Tratt wrote: > I've had a Ryzen machine with a (basic!) Polaris GPU for about a year. Over > that time nearly all of the GPU related bugs have disappeared (thanks > Jonathan et al.!), except for the fact that I don't seem to be able to > reliably suspend/resume from X. I thought it might be worth noting that, unfortunately, despite amdgpu and mesa updates this machine still can't reliably suspend or resume once X is doing something. [From the non-X terminal, suspend/resume works fine.] Since I guess this machine is now fairly standard hardware, I wonder if there's some obvious X or BIOS setting that I should be tweaking, but nothing I've tried seems to help so far! In case it's useful here's today's dmesg, where when I tried to suspect the display did (as expected) stop displaying anything, but the machine did not stop running (e.g. the fans & lights didn't turn off): OpenBSD 7.1-current (GENERIC.MP) #509: Mon May 9 22:13:31 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34211557376 (32626MB) avail mem = 33157357568 (31621MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xcb9f7000 (72 entries) bios0: vendor American Megatrends Inc. version "2423" date 08/09/2021 bios0: ASUS ROG STRIX B550-E GAMING acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT FIDT FPDT MCFG HPET IVRS VFCT BGRT WPBT PCCT SSDT CRAT CDIT SSDT SSDT SSDT SSDT WSMT APIC SSDT SSDT acpi0: wakeup devices GP12(S4) GP13(S4) XHC0(S4) GP30(S4) GP31(S4) X161(S4) X162(S4) PTXH(S4) X1_1(S4) X1_2(S4) WIFI(S4) I225(S4) X163(S4) M2_2(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 9 5900X 12-Core Processor, 3700.48 MHz, 19-21-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: AMD Ryzen 9 5900X 12-Core Processor, 3700.01 MHz, 19-21-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: AMD Ryzen 9 5900X 12-Core Processor, 3700.00 MHz, 19-21-00 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: AMD Ryzen 9 5900X 12-Core Processor, 3700.01 MHz, 19-21-00 cpu3:
Re: [External] : 7.1-Current crash with NET_TASKQ 4 and veb interface
Thanks for your support. I'll try to test when you get it done.
On Mon, May 9, 2022 at 8:51 PM Alexandr Nedvedicky <
alexandr.nedvedi...@oracle.com> wrote:
> Hello Barbaros,
>
> thank you for testing and excellent report.
>
>
>
> > ddb{1}> trace
> > db_enter() at db_enter+0x10
> > panic(81f22e39) at panic+0xbf
> > __assert(81f96c9d,81f85ebc,a3,81fd252f) at
> __assert+0x25
> > assertwaitok() at assertwaitok+0xcc
> > mi_switch() at mi_switch+0x40
>
> assert indicates we attempt to sleep inside SMR section,
> which must be avoided.
>
> > sleep_finish(800025574da0,1) at sleep_finish+0x10b
> > rw_enter(822cfe50,1) at rw_enter+0x1cb
> > pf_test(2,1,8520e000,800025575058) at pf_test+0x1088
> > ip_input_if(800025575058,800025575064,4,0,8520e000) at
> ip_input_if+0xcd
> > ipv4_input(8520e000,fd8053616700) at ipv4_input+0x39
> > ether_input(8520e000,fd8053616700) at ether_input+0x3ad
> > vport_if_enqueue(8520e000,fd8053616700) at
> vport_if_enqueue+0x19
> >
> veb_port_input(851c3800,fd806064c200,,82066600)
> at veb_port_input+0x4d2
> > ether_input(851c3800,fd806064c200) at ether_input+0x100
> > vlan_input(8095a050,fd806064c200,8000255752bc) at
> vlan_input+0x23d
> > ether_input(8095a050,fd806064c200) at ether_input+0x85
> > if_input_process(8095a050,800025575358) at
> if_input_process+0x6f
> > ifiq_process(8095a460) at ifiq_process+0x69
> > taskq_thread(80035080) at taskq_thread+0x100
>
> above is a call stack, which has done a bad thing (sleeping SMR
> section)
>
> in my opinion the primary suspect is veb_port_input() which code reads as
> follows:
>
> 966 static struct mbuf *
> 967 veb_port_input(struct ifnet *ifp0, struct mbuf *m, uint64_t dst, void
> *brport)
> 968 {
> 969 struct veb_port *p = brport;
> 970 struct veb_softc *sc = p->p_veb;
> 971 struct ifnet *ifp = >sc_if;
> 972 struct ether_header *eh;
> ...
> 1021 counters_pkt(ifp->if_counters, ifc_ipackets, ifc_ibytes,
> 1022 m->m_pkthdr.len);
> 1023
> 1024 /* force packets into the one routing domain for pf */
> 1025 m->m_pkthdr.ph_rtableid = ifp->if_rdomain;
> 1026
> 1027 #if NBPFILTER > 0
> 1028 if_bpf = READ_ONCE(ifp->if_bpf);
> 1029 if (if_bpf != NULL) {
> 1030 if (bpf_mtap_ether(if_bpf, m, 0) != 0)
> 1031 goto drop;
> 1032 }
> 1033 #endif
> 1034
> 1035 veb_span(sc, m);
> 1036
> 1037 if (ISSET(p->p_bif_flags, IFBIF_BLOCKNONIP) &&
> 1038 veb_ip_filter(m))
> 1039 goto drop;
> 1040
> 1041 if (!ISSET(ifp->if_flags, IFF_LINK0) &&
> 1042 veb_vlan_filter(m))
> 1043 goto drop;
> 1044
> 1045 if (veb_rule_filter(p, VEB_RULE_LIST_IN, m, src, dst))
> 1046 goto drop;
>
> call to veb_span() at line 1035 seems to be our guy/culprit (in my
> opinion):
>
> 356 smr_read_enter();
> 357 SMR_TAILQ_FOREACH(p, >sc_spans.l_list, p_entry) {
> 358 ifp0 = p->p_ifp0;
> 359 if (!ISSET(ifp0->if_flags, IFF_RUNNING))
> 360 continue;
> 361
> 362 m = m_dup_pkt(m0, max_linkhdr + ETHER_ALIGN,
> M_NOWAIT);
> 363 if (m == NULL) {
> 364 /* XXX count error */
> 365 continue;
> 366 }
> 367
> 368 if_enqueue(ifp0, m); /* XXX count error */
> 369 }
> 370 smr_read_leave();
>
> loop above comes from veb_span(), which calls if_enqueue() from within
> a smr section. The line 368 calls here:
>
> 2191 static int
> 2192 vport_if_enqueue(struct ifnet *ifp, struct mbuf *m)
> 2193 {
> 2194 /*
> 2195 * switching an l2 packet toward a vport means pushing it
> 2196 * into the network stack. this function exists to make
> 2197 * if_vinput compat with veb calling if_enqueue.
> 2198 */
> 2199
> 2200 if_vinput(ifp, m);
> 2201
> 2202 return (0);
> 2203 }
>
> which in turn calls if_vinput() which calls further down to ipstack, and IP
> stack my sleep. We must change veb_span() such calls to if_vinput() will
> happen
> outside of SMR section.
>
> I don't have such complex setup to use vlans and virtual ports. I'll try to
> cook some diff and pass it to you for testing.
>
> thanks again for coming back to us with report.
>
> regards
> sashan
>
>
>
Re: uhid spam: uhidev_intr: bad repid 33
On Mon, May 09, 2022 at 05:44:29PM +0100, Stuart Henderson wrote: > I have a USB combi keyboard/trackpad thing which is triggering "bad > repid 33" frequently while attached (between a couple of times a minute, > and once every few minutes). It does work but it's annoying. > > Presumably this is because it has non-contiguous report IDs? > Anyone have an idea how to handle it? Could you send me the raw report descriptors: $ (set -e; i=0; while :; do doas usbhidctl -f /dev/uhid$i -R >/tmp/uhid$i.raw; i=$((i + 1)); done)
