On Mon, Jun 06, 2011 at 04:24:13PM -0400, Dave Anderson wrote: > On Fri, 3 Jun 2011, Dave Anderson wrote: > > >On Fri, 3 Jun 2011, Kenneth R Westerback wrote: > > > >>On Fri, Jun 03, 2011 at 01:09:47PM -0400, Dave Anderson wrote: > >>> While gathering notebook dmesgs I encountered this panic during boot (at > >>> a Best Buy, on a demo system labelled Toshiba r835-p50x, booting from > >>> a USB stick loaded with an i386 snapshot dated 5/24). The root device > >>> DUID shown is correct. > >>> > >>> panic: root device (e0166bb8f33fc15d) not found > >>> stopped at Debugger_0x4: popl %ebp > >>> > >>> [trace] > >>> Debugger(d08e2194.d0ba9d54.d08bf2f0.d0ba9d54.15c6a) at Debugger+0x4 > >>> panic(d08bf2f0.e0.16.6b.b8) at panic+0x5d > >>> setroot(d3a99800.0.4000.d0ba9e94.0) at setroot+0xa05 > >>> diskconf(d08b73d7.0.d08bd109.0,0) at diskconf+0x12e > >>> main(d02004ba.d02004c2.0.0.0) at main+0x570 > >>> > >>> [ps] > >>> PID PPID PGRP UID S FLAGS WAIT COMMAND > >>> 9 0 0 0 3 0x100200 bored crypto > >>> 8 0 0 0 3 0x100200 pftm pfpurge > >>> 7 0 0 0 3 0x100200 usbtsk usbtask > >>> 6 0 0 0 3 0x100200 usbatsk usbatsk > >>> 5 0 0 0 3 0x100200 acpi0 acpi0 > >>> 4 0 0 0 3 0x100200 bored syswq > >>> 3 0 0 0 3 0x40100200 idle0 > >>> 2 0 0 0 3 0x100200 kmalloc kmthread > >>> 1 0 0 0 3 0 initexec swapper > >>> * 0 -1 0 0 7 0x80200 swapper > >>> > >>> [All of the above was hand-copied from the screen, so there may be > >>> typos.] > >>> > >>> I hope that this is enough information to enable someone to track down > >>> the problem. If more is needed, let me know what it is and I'll try to > >>> get it. > >>> > >>> Dave > >>> > >>> -- > >>> Dave Anderson > >>> <d...@daveanderson.com> > >> > >>The dmesg is needed. This looks like the disk/usb stick is not being > >>found by the OS. > > > >I was afraid of that. > > > >Dealing with the first apparent problem, that most of the dmesg scrolls > >off the screen, looks to be easy; a quick look at the source reveals > >that ddb has an apparently undocumented 'dmesg' command. > > > >Actually capturing the dmesg looks to be harder; given that this is a > >store demo system to which I have very limited access I'm not sure I've > >got any better way than hand-writing it all. I've got a couple of ideas > >for easier ways to try, but it will take a few days. Are there any > >parts of the dmesg that are known to be unnecessary for this purpose, so > >I can avoid the work of copying them if I have to fall back to writing > >everything down and retyping it? > > > >Now that I've had time to think about this a bit, I'd guess that the > >problem is some new USB controller that OpenBSD doesn't yet understand. > >If so, am I correct that all that's really needed is the vendor ID and > >device ID of the controller? I'll check for this first, now that I know > >how to view the whole dmesg after the panic. > > > >FWIW this stick boots just fine on lots of other systems, both before > >and after this problem system. > > I got a chance to poke at this system again today, and found a USB port > from which I could boot. The offending device appears to be '"NEC > PCIE-XHCI" rev 0x04 at pci4 dev 0 function 0 not configured'. I also > found another system (labelled Dell Inspiron 17r-6457dbk) which exhibits > a similar problem but again was able to find a working USB port; this > appears to use the same new device: '"NEC PCIE-XHCI" rev 0x04 at pci2 > dev 0 function 0 not configured'. > > I'm sending both dmesgs to dm...@openbsd.org and also including them > here in case that's useful.
Excellent! Thanks for the investigation. XHCI sounds like usb3, and I don't believe we support that yet. .... Ken
