Subject: port-i386/4718: block size of 4MB in dd (run as root) causes i386 kernel panic
To: None <gnats-bugs@gnats.netbsd.org>
From: None <oster@cs.usask.ca>
List: netbsd-bugs
Date: 12/18/1997 10:10:15
>Number:         4718
>Category:       port-i386
>Synopsis:       block size of 4MB in dd (run as root) causes i386 kernel panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 18 08:20:00 1997
>Last-Modified:
>Originator:     Greg Oster
>Organization:
>Release:        NetBSD 1.3_BETA compiled from December 8, 1997 sources.
>Environment:

System: NetBSD merlin 1.3_BETA NetBSD 1.3_BETA (MERLIN) #0:
Tue Dec 16 20:58:31 CST 1997
oster@merlin:/quantum/current.i386/src/sys/arch/i386/compile/MERLIN
i386


>Description:

Running the following as root (the problem doesn't happen if run as a 
regular user):

        dd if=/dev/rsd0d of=/dev/null bs=4m count=10

causes a:

        panic: ptdi 1e03063

to occur (the latter number varies, depending on how much RAM is in
the system, the block size requested, etc.).  One can achive the same
effect with the same "dd" command, using "bs=10m" in place of "bs=4m",
or by replacing "rsd0d" with "rwd0d".  The machine in use here is a
P133 w/ 128MB of RAM.

As a datapoint, a Sun 3/50 compiled from the exact same Dec. 8/97 
sources works successfully with "bs=4m".  With "bs=10m" the 3/50 says:

  dd: : Cannot allocate memory

An Amiga 3000, again from the same sources, exhibits the same
behaviour as the Sun, so this really looks like an i386-specific
problem.

The trace from the i386's panic is (assuming no typo's in the numbers):

db> trace
_Debugger(f0a17600,f7d59cf8,f01cb3ad,f01cb350,3925063) at _Debugger+0x4
_panic(f01cb350,3925063,f0a17600,f03ccb28,0) at _panic+0x46
_pmap_enter(f0a19a80,400000,3d5100,7,1) at _pmap_enter+0x55
_vm_fault(f0a15500,400000,7,1) at _vm_fault+0xbca
_vm_fault_wire(f0a15500,3fd000,40d000,f0ee87f8,1) at _vm_fault_wire+0x35
_vm_map_pageable(f0a15500,3fd000,40d000,0,f7d59e18) at _vm_map_pageable+0x291
_vslock(3fd000,10000,f7d59ea0,f7d59ed8,f0a06000) at _vslock+0x2a
_physio(f01d3ee8,0,d03,100000,f01d4268) at _physio+0x1bc
_sdread(d03,f7d59f20,0,f09e3c80,f0a17200) at _sdread+0x1f
_spec_read(f7d59ed8,f7d59eec,f013f607,f7d59ed8,a00000) at _spec_read+0xb1
_ufsspec_read(f7d59ed7,a00000,3,f0a06000,f7d59ed8) at _ufsspec_read+0x21
_vn_read(f0a18e80,f7d59f20,f0a17200) at _vn_read+0xaf
_sys_read(f0a06000,f7d59f88,f7d59f80,0,efbfdc00) at _sys_read+0xa3
_syscall() at _syscall+0x21c
--- syscall (number 3) ---
0xb5cf:
db>

I suspect this problem is similar to (if not the same as) the problem
reported in PR#4505.

>How-To-Repeat:

Do (as root) a:

        dd if=/dev/rsd0d of=/dev/null bs=4m count=10

or a:

        dd if=/dev/rwd0d of=/dev/null bs=4m count=10

and watch as the i386 box panics.  Might have to use a larger block
size to make it go boom.

>Fix:

Not a clue.

>Audit-Trail:
>Unformatted: