release building failure

[Robert Garrett]

Robert Garrett wrote:

> Matthew Dillon wrote:
> 
> 
>> 
>>     I think Jeff brought up the NULL vs NODEV issue.  I'm sure there are
>>     issues in the tree but also that they are going to be fairly easy to
>>     fix.  If you can come up with a DDB>  back trace from the panics I'll
>>     bet the problems can be fixed fairly quickly.
>> 
>> -Matt
>> Matthew Dillon
>> <dillon at xxxxxxxxxxxxx>
> 
> coming up shortly, I've reduced this to the problem area, and can now
> cause the panic easily, I've got a test box on remote console but for
> some reason NFS is perty slow.
> 
> what I have at this moment is..
> relevent chunk from nm -v /kernel
> 
> c01567e4 T dev_dname
> c0156814 T dev_dflags
> c0156848 T dev_dmaj
> c015687c T dev_dport
> c01568d8 T compile_devsw
> 
> 
> udev2dev: attempt to lookup block dev(69378)
> udev2dev: attempt to lookup block dev(3842)vnstrategy(0xcc5a3f6c): unit 1
> vnstrategy(0xcc5a3f6c): unit 1
> 
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address     = 0x2c
> fault code                = supervisor read, page not present
> instruction pointer       = 0x8:0xc0156885
> stack pointer             = 0x10:0xdb2e4aa0
> frame pointer             = 0x10:0xdb2e4aac
> code segment              = base 0x0, limit 0xfffff, type 0x1b
>                           = DPL 0, pres 1, def32 1, gran 1
> processor eflags          = interrupt enabled, resume, IOPL
> 
> The trace on my workstation ends at dev_dport btw.
> DDB trace coming soon ..
> 
> Rob
and finally the trace,

dev_dport(0) at dev_dport+0x9
spec_open(c4734b18,c4734af0,c0333581,c4734b18,c4734b8c) at spec_open+0x27
spec_vnoperate(c4734b18,c4734b8c,c026164b,c4734b18,c3e86680) at
spec_vnoperate+0x15
ufs_vnoperatespec(c4734b18,c3e86680,c3e7d740,c0ce2680,c4726300) at
ufs_vnoperate
spec+0x15
vn_open(c4734be8,3,46c,c0444988,c3e7d740) at vn_open+0x3df
open(c4734c80,0,bfbffb84,806848b,c4734d20) at open+0xdc
syscall2(2f,2f,2f,806848b,bfbffb84) at syscall2+0x276
Xint0x80_syscall() at Xint0x80_syscall+0x2a