On Sun, Feb 23, 2014 at 12:07:33PM +0000, David Laight wrote: > On Sun, Feb 23, 2014 at 12:32:05PM +0100, Thomas Klausner wrote: > > On Sun, Feb 23, 2014 at 10:41:06AM +0100, Thomas Klausner wrote: > > > After updating from 6.99.31/20140215 to 6.99.31/20140221, I started X > > > and got a panic: > > > > > > fatal protection fault in supervisor mode > > > trap type 4 code 0 rip ffffffff808dbe2c cs 8 rflags 13286 cr2 > > > ffff80023b989000 ilevel 0 rsp fffffe813ba2e9b0 > > > curlwp 0xfffffe813ba139c0 pid 328.1 lowest kstack 0xfffffe813ba2b280 > ... > > > --- trap (number 4) --- > > > usb_allocmem_flags() at netbsd:usb_allocmem_flags+0x6c > > > ehci_allocm() at netbsd:ehci_allocm+0x2a > ... > > > After a reboot I tried again (while logged in via ssh, not via the USB > > > keyboard like before) and it worked. > > > > I could also start from the console, so it seems to have a random > > element. > > > > Why did I need to start so soon? Because of a second panic. > > > > panic: kernel diagnostic assertion "len <= LINUX32_ELF_AUX_ENTRIES" failed: > > file "/archive/foreign/src/sys/compat/linux32/common/linux32_exec_elf32.c", > > line 244 > > cpu7: Begin traceback... > > vpanic() at netbsd:vpanic+0x1cd > > kern_assert() at netbsd:kern_assert+0x5a > > linux32_elf32_copyargs() at netbsd:linux32_elf32_copyargs+0x407 > ... > > This happened during a bulk build, I guess building one of the suse > > packages. I'll retry. > > Hmmm... these could be 'random' panics. > Might be worth looking for a latter working kernel. > Or look through the commits for something suspicious and try the other > side of it. > > To even attempt to diagnose the crash we'd need a working kernel dump. > (Do those work on amd64 at the moment - if you are willing to wait > for the hours it takes to write out 16GB ...)
Oddly I also saw an X crash like that once, and then couldn't repeat it. And I saw the linux problem yesterday when doing pkg_delete suse12_x11. Must hunt for dumps... Cheers, Patrick