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 ...) David David -- David Laight: da...@l8s.co.uk