reproducible panic in netisr

[Bjoern A. Zeeb]

On Mon, 10 Aug 2009, Robert Watson wrote:

>
> On Mon, 10 Aug 2009, Julian Elischer wrote:
>
>>> One possible workaround would be to force the __start_ symbol and the 
>>> section to be equally aligned and thus on the same address using linker 
>>> scripts.  The drawbacks are that we need to touch the fragile linker 
>>> scripts for each of the sections we add and for all architectures 
>>> individually.  As the enforcement of alignment would be at a different 
>>> place to the actual set creation, putting the alignment in might be easily 
>>> forgotten.
>> 
>> personally I'd see if there is a way to align the section on a page 
>> boundary..
>
> I'm not sure it matters for the master copy, but I believe some (if not all) 
> architecture MD parts already allocate the per-CPU data areas as 
> page-aligned, and we extend the master copy out to a page boundary.  That 
> said, it would be worth checking on a run-time kernel to make sure it works 
> out that way in practice.

db> show dpcpu_off
dpcpu_off[ 0] = 0x42b100 (+ DPCPU_START = 0xffffffff81002000: aligned)
dpcpu_off[ 1] = 0xffffff807f44e100 (+ DPCPU_START = 0xffffff8000025000: aligned)
dpcpu_off[ 2] = 0xffffff807f455100 (+ DPCPU_START = 0xffffff800002c000: aligned)
dpcpu_off[ 3] = 0xffffff807f45c100 (+ DPCPU_START = 0xffffff8000033000: aligned)
dpcpu_off[ 4] = 0xffffff807f463100 (+ DPCPU_START = 0xffffff800003a000: aligned)
dpcpu_off[ 5] = 0xffffff807f46a100 (+ DPCPU_START = 0xffffff8000041000: aligned)
dpcpu_off[ 6] = 0xffffff807f471100 (+ DPCPU_START = 0xffffff8000048000: aligned)
dpcpu_off[ 7] = 0xffffff807f478100 (+ DPCPU_START = 0xffffff800004f000: aligned)

Note: you don't have that ddb command.  I added that last week to my
kernel for debugging.

But that's nothing I wouldn't have expected as we are using
kmem_alloc() for dpcpu.

The more intersting thing would be to see what malloc does for vnet,
even if we are memeory multiple of page sizes.  An updated show vnets
gives:

db> show vnets
vnet            = 0xffffff0005c4ab00
  ...
  vnet_data_mem  = 0xffffff8000b00000
  vnet_data_base = 0xffffff807ff81f80
vnet            = 0xffffff0005c278c0
  ...
  vnet_data_mem  = 0xffffff8000ab8000
  vnet_data_base = 0xffffff807ff39f80
vnet            = 0xffffff0001633dc0
  ...
  vnet_data_mem  = 0xffffff8000226000
  vnet_data_base = 0xffffff807f6a7f80

So looking at vnet_data_mem this looks good as well:)


/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.