> > Hope someone can tell me where to debug this further (Manuel
> > Bouyer, are you there?  This sounds like "your ball"... ;-)
>
> I'm there! Starting a remote debug session in private mail...

...which turned out successful, seen from my point of view --
thanks to Manuel!  I'm think Manuel Bouyer will commit the fix
(or something like it).  The problem was (if I understood
correctly) that a the probe and/or attach routine left the
controller with a nonexistant drive selected.


But the story continues, this time with "interesting" VM
problems, it would seem...


After installing the fix, I came a little longer -- I got the
prompt for "install / shell / update", answered "shell", did
"more /kern/msgbuf" and the following commands:

# ifconfig lo0 inet 127.0.0.1 up
# ifconfig ep0 inet 129.241.100.149 netmask 0xffffff00 up
(here I got the earlier mentioned "missing" "pcmcia1: card irq 7" message) 
# route add default 129.241.100.1

and after the last one I got "panic: lockmgr: locking against
myself".  Some output from DDB follows (copied by hand, no serial
console yet...):

db> trace
_Debugger(f08f0a04,f3c5ddac,f011345b,f011310d,f08f0a04) at _Debugger+0x4
_panic(f011310d,f08f0a04,efd01000,f08f0a00,3) at _panic+0x46
_lockmgr(f08f0a04,2,0,f08eea00) at _lockmgr+0x2ab
_vm_map_pageable(f08f0a00,efd00000,efd01000,0) at _vm_map_pageable+0x29
_trap() at _trap+0x481
--- trap (number 6) ---
_vm_object_copy(f08f2400,0,f0000,f08f3c90,f08f3c94,f3c5deb4) at _vm_object_copy+0x44
_vm_map_copy_entry(f08f0a00,f08f4500,f08ec500,f08f3c80) at _vm_map_copy_entry+0xf5
_vmspace_fork(f08f0a00,f08f0a00,efbfe000,effbf000,2) at _vmspace_fork+0x22b
_fm_fork(f08eea00,f08ee600) at _vm_fork+0x2b
_fork1(f08eea00,0,f3c5df80,f3c5dfa8,f019d8f1) at _fork1+0x373
_sys_fork(f08eea00,f3c5df88,f3c5df80) at _sys_fork+0x10
_syscall() at _syscall+0xf5
--- syscall (number 2) ---
0xcc253:
db> ps
  pid proc     addr     uid  ppid  pgrp  flag stat em  comm       wchan
   19 0xf08ee600 0xf3c60000   0     3     3  000006  1  netbsd  sh
    7 0xf08ee200 0xf3c63000   0     1     7  000084  3  netbsd  cat   pause 0xf3c63194
    3 0xf08eea00 0xf3c5c000   0     1     3  004006  2  netbsd  sh
    2 0xf08eec00 0xf3c59000   0     0     0  000204  3  netbsd  pagedaemon   trd_sleep 0xf0346778
    1 0xf08eee00 0xf3c56000   0     0     1  004084  3  netbsd  init    wait 0xf08eee00
    0 0xf0349c1c 0xf0370000   0    -1     0  000204  3  netbsd  swapper   scheduler 0xf0349c1c
db>


I tried to repeat this, and the error symptoms the second time
weren't exactly the same (I had left out the "more /kern/msgbuf"
command), and this attempt ended up with:

Data modified on freelist: word 0 of object 0xf08f2400 size 76 previous type mbuf (0xdead0069 != 0xdeadbeef)
Data modified on freelist: word 0 of object 0xf08f2980 size 76 previous type mbuf (0xdead2502 != 0xdeadbeef)
panic: vm_object_bypass: busy or fake page in backing_object
Stopped at     _Debugger+0x4:  leave
db> trace
_Debugger(73000,f3c5dee4,f018e0be,f018e03b,f08f2980) at _Debugger+0x4
_panic(f018303b,f08f2980,f0442d10,6a0000,f08f2980) at _panic+0x46
_vm_object_bypass(f08f2980) at _vm_object_bypass+0x4a
_vm_object_collapse(f08f2980) at _vm_object_collapse+0x66
_vm_fault(f08f0a00,1fd000,3,0) at _vm_fault+0x575
_trap() at _trap+0x498
--- trap (number 6) ---
0xeef51:
db>


A third attampt (exactly the same as the first one above),
resulted in:

Data modified on freelist: word 0 of object 0xf08f1180 size 128 previous type VM object (0xdead0000 != 0xdeadbeef)

which came before the "route add default..." command was
completely typed in, and then, when I started route:

panic: vm_object_bypass: busy or fake page in backing_object

(DDB trace omitted, it looks similar to the 2nd above.)


Any ideas what may be the problem here?  It would seem to me that
some part of the kernel is misbehaving and clobbering data where
it should not.  If anyone need more information regarding this
one, I can dig out whatever DDB can give me if someone give me
enough directions...

- Havard