Hi, I have isolated my problem to ehci.c by brute force printfs. NB: jakemsr@ is helping me out on this issue.
I thought how would I go about finding this bug? This is a USB keyboard bug, this machine has no PS/2 just USB ports. As soon as it hits that usb_allocmem, it drops me into ddb without a working keyboard. jakemsr@ helped me out by mentioning to setup a sshd to get access. I initially disabled uhub in UKC and did the kernel compiles. Later on I found out that disabling ehci in UKC works better as problem goes away and I get keyboard access on machine, in addition to sshd access. NVidia EHCI has problems for all OS (NetBSD, FreeBSD, Windows) but I am stuck here. Ok but since the crash happens before filesystems checks or network is started I can't get to the machine keyboard at all to trace the dump in ddb. I compiled with makeoptions DEBUG="-g", I tried kgdb. No dice. How to get the stack trace? Finally it led to http://www.daemon-systems.org/man/ddb.4.html options DDB_COMMANDONENTER="trace;show registers" So again I entered this in my GENERIC options DDB_COMMANDONENTER="trace" makeoptions DEBUG="-g" but it doesn't show a stack trace at all when dropping into ddb. And I ca't type anything during that time because the keyboard is inoperative! Does this kernel options work or is that page outdated? I didn't get a complaint during kernel compile. Ideally, how can I force a kernel dump with stacktrace and with offending line number information displayed without doing anything in ddb? I personally would always have it on in my GENERIC config. Thanks On Tue, Oct 26, 2010 at 11:29 AM, Amit Kulkarni <[email protected]> wrote: > Hi, > > I managed to cvs update of 4.8 stable sources, do a rebuild of config (it > needed mandoc and libc.so.57.0 which I grabbed from Oct 22 snapshot), did a > build of 4.8 stable kernel, and booted. Please don't flame on incompatible > libc & mandoc, I just wanted to see where it fails exactly. At least now it > shows a ddb prompt when it fails instead of press any key to reboot. prompt > doesn't accept any key press at all. > I copied the exact message from screen, hoping it would catch something > helpful to somebody. > uhub2 at uhub0 port 7 "Standard Microsystems product 0x2502" rev 2.00/0.01 > addr2 > kernel: protection fault trap, code=0 > Stopped at usb_allocmem+0x83: cmpq %rbx,0(%rax) > Thanks > On Tue, Oct 26, 2010 at 11:03 AM, Amit Kulkarni <[email protected]> wrote: >> >> Hi, >> >> I am trying to get a old Sun Ultra 40 AMD64 to work on OpenBSD (preferably >> current). I have tried many different snapshots of 4.8 current (I will try >> on the 4.8 stable later in a week or so!) >> I copied bsd.rd from the Oct 22 snapshot as /nbsd.rd, went to the UKC to >> set with verbose option but it scrolls too fast to see exactly what's the >> problem. I don't have a floppy or serial console on this machine so can't >> save the dmesg somewhere. I get a fatal protection fault in supervisor mode, >> press any key to reboot (it happens near the uhubN lines in the scrolling >> dmesg around the Pentium MTRR line). >> 4.7 installs fine, but X won't work as this machine has a NVIDIA Quadro FX >> 380 (graphics card failed after 3 years), which is probably in 4.8 stable >> according to this page (change in May 2010) >> >> http://www.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-nv/src/nv_dr iver.c >> I have emailed the dmesg from 4.7. What can I do to get the dmesg from the >> -current bsd.rd to help diagnose what's wrong or what changed? >> Thanks for help
