Re: (maybe) crash your VAX from userspace

I have a MicroVAX II with a DEQNA.  I'll test it this weekend -- I have a bunch of 10 RC testing and upgrading to do.  I already have that system netbooting RC1, so I'll test with that first.

Kind regards,
Josh/NODOMAIN.NET


On Mar 22, 2024, at 17:49, Johnny Billquist <[email protected]> wrote:

I hope there is someone with a Qbus VAX up and running. I have one in storage where I live which I could eventually drag up, but won't happen in the very near future...

 Johnny

On 2024-03-23 01:37, Alexander Schreiber wrote:
Hi,
do you have a real metal VAX? Do you run NetBSD 10.0 RC6 on it? Are
you ok with (maybe) crashing it? Then you are the person I'm looking
for (maybe)!
While I was investigating network-activity related SIMH/vax crashes
(as in: the simulator segfaulted), I tried to test with smaller MTU
size to check a theory. So I ran "ifconfig qe0 mtu 512" ... at which
point I got this:
ifconfig qe0 mtu 512
[ 459.2554210] r0=87fd9028 r1=00000000 r2=00000000 r3=87a2e500 r4=80692f34 r5=00000000 r6=87fd9028 r7=87e91b80
[ 459.2554210] r8=00000000 r9=87e91b80 r10=8090697f r11=00000000
[ 459.2554210] ap=8b869c7c fp=8b869c68 sp=7ffff50c pc=80259431
[ 459.2554210] panic: SEGV in kernel mode: pc 0x80259431 addr 0
[ 459.2554210] cpu0: Begin traceback...
[ 459.2554210] panic: SEGV in kernel mode: pc 0x80259431 addr 0
[ 459.2554210] Stack traceback :
[ 459.2554210]   Process is executing in user space.
[ 459.2554210] cpu0: End traceback...
 [ 459.2554210] dump to dev 9,1 not possible
 HALT instruction, PC: 80013565 (PUSHAB 802A2F6B)
Goodbye
I _suspect_ this is a driver specific issue. So we need:
 - a real metal VAX
 - that has the qe ethernet device
 - that runs NetBSD 10.0 RC6
 - that you are ok with crashing
Your mission, if you choose to accept it, is to run "ifconfig qe0 mtu 512"
on your VAX and report back what happens. Three likely outcomes:
 - ifconfig tells you to bugger off (happened with NetBSD 5.0.2 where
   I got "ifconfig: SIOCSIFMTU: Invalid argument"
 - it works and then the kernel complains about oversized frames
   (behaviour on 9.3 with sparc64) which is Working As Expected
 - you get a kernel crash
If you don't run 10.0 RC6, I've reproduced this as far back as 8.0
and I've got a PR primed to go, but before I file it, I want to make
sure this actually also happens on real hardware and is not a weird
simulator edge case. If it doesn't happen on real hardware, well,
then I've got a different tree to bark up to ...
Bold volunteers wanted!
Kind regards,
          Alex.

--
Johnny Billquist                  || "I'm on a bus
                                 ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol