On Fri, Feb 20, 2015 at 10:15:15PM -0330, Michael wrote: > On 20 February 2015 at 05:03, Stuart Henderson <st...@openbsd.org> wrote: > > On 2015/02/19 17:30, Mike Larkin wrote: > >> On Thu, Feb 19, 2015 at 09:02:42PM -0330, Michael wrote: > >> > > > >> > > There's a slim chance that killing processes (sshd, smtpd, dhclient, > >> > > cron, pflogd, ntpd) might free up enough to help. > >> > > > >> > > Maybe also worth trying ddb.console=0, it will try to print a stack > >> > > trace and then reboot rather than entering ddb. > >> > > > >> > > >> > New and updated output after stopping the processes and setting > >> > ddb.console=0, however ddb is still entered and there wasn't a stack > >> > trace. > >> > >> I think ddb.panic was what he meant? > > > > Yes, sorry. > > > > No worries, got that below in the first few sections. > I then decided to test in another machine that I have (noted as ---- > dell) and the same thing happens. The dell has much more memory so > should hopefully make debugging/compiling easier if you need anything. > ---- > sudo ifconfig bwi0 up > uvm_fault(0xd211a2d0, 0x0, 0, 1) -> e > fatal page fault (6) in supervisor mode > trap type 6 code 0 eip 0 cs d0f60008 eflags 10202 cr2 0 cpl 60 > panic: trap type 6, code=0, pc=0 > Starting stack trace... > panic(d09e1dca,f11adc10,d09e5a96,f11adc10,d0b3330c) at panic+0x85 > panic(d09e5a96,6,0,0,d0f60008) at panic+0x85 > trap() at trap+0x394 > --- trap (number 0) --- > Bad frame pointer: 0xd0f69000 > 0: > End of stack trace. > syncing disks... 4 4 4 done
So it's running into a NULL pointer but it's still unclear where and why. Perhaps it's an unchecked allocation failure, perhaps some other problem. Are you comfortable with adding some debug printf to see which function in bwi is the last called one before the crash? Would you need help with that?
