On Fri, Jul 10, 2020 at 08:31:29AM +0100, Ricardo Mestre wrote: > Hi, > > Since my edgerouter decided to commit seppuku, then to replace it, the cheap > bastard in me bought a crappy braswell based device which after 2 months > finally arrived, but of course it had to have at least one problem. > > As soon as inteldrm attach I get the below panic, but with inteldrm disabled > I'm able to boot and use the system without issues: > > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > wsdisplay0: screen 1-5 added (std, vt100 emulation) > kernel: protection fault trap, code=0 > Stopped at pool_do_put+0xd0 movq 0x8(%rcx),%rcx > > This is the trace without function params, typed manually since this box > doesn't have serial console, but link [0] has them. Any clues about this > or should I just dump it in the fire? > > [0] https://imgur.com/a/O5PFQpz > > ddb{1}> trace > pool_do_put() at pool_do_put+0xd0 > pool_put() at pool_put+0x5a > uvm_unmap_detach() at uvm_unmap_detach+0x90 > uvm_map() at uvm_map+0x7fb > km_alloc() at km_alloc+0x162 > pool_multi_alloc_ni at pool_multi_alloc_ni+0xa6 > pool_p_alloc() at pool_p_alloc+0x5a > pool_do_get() at pool_do_get+0xd3 > pool_get() at pool_get+0x8f > ufsdirhash_build at ufsdirhash_build+0x314 > ufs_lookup() at ufs_lookup+0x18a > VOP_LOOKUP() at VOP_LOOKUP+0x46 > vfs_lookup() at vfs_lookup+0x3d2 > namei() at namei+0x3a5 > start_init() at start_init+0xaa > end trace frame: 0x0, count: -15
reports like this should go to bugs@ not tech Most of the pool use in drm is quite mechanical conversions of kmem_cache*. The only suspect thing I can spot is in a detach path, which isn't involved if a wsdisplay is being attached. I can't reproduce this here on a braswell system with the same kernel from snapshots or a locally built kernel.
