Ed Maste
Ed Maste
The driver works for me (for 10 minutes so far) with similar changes in intel_pipe_update_start and intel_pipe_update_end. I'll submit a pull request for these ones, but there are other cases...
I have #388 in my local tree and encountered a similar kind of panic (not yet investigated in more detail) ``` [9363.841314] panic: mi_switch: switch in a critical section [9363.891278]...
- `intel_update_crtc` calls `intel_pipe_update_start` which calls `preempt_disable` - fwtable_read* calls `spin_lock_irqsave(&uncore->lock, irqflags);`
I am running it now and will let you know.
At 3c86e7b03112fa898bb08c1f3637f1dc61c2e1a5, still encountered: ``` [137367.046182] panic: mi_switch: switch in a critical section [137367.086751] cpuid = 6 [137367.092883] time = 1770223261 [137367.099178] KDB: stack backtrace: [137367.105818] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00ff5f48f0...
> Besides that startx/X11 crashes the vm As in, VirtualBox crashes? If so that should be a bug report there.
Other than @tdz there are 6 authors in sysfb/ with one commit each, all relatively straightforward. But `git-blame` shows @tdz for 95% of sysfb so dual-licensing is a nonstarter.
The equivalent functionality in the OpenBSD driver is: ``` if (rxd_type & (AQ_RXDESC_TYPE_VLAN | AQ_RXDESC_TYPE_VLAN2)) { m->m_pkthdr.ether_vtag = lemtoh16(&rxd->vlan); m->m_flags |= M_VLANTAG; } ``` and I suspect this should be...
https://reviews.freebsd.org/D53836
looks reasonable