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
>> <[email protected]>
>
>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.
Dave
--
Dave Anderson
<[email protected]>