Bug 13940

Summary:	Panic with dd on block/"cooked" devices using 3.3-RELEASE
Product:	Base System	Reporter:	Phil Regnauld <regnauld>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	3.3-RELEASE
Hardware:	Any
OS:	Any

Description Phil Regnauld 1999-09-25 02:10:01 UTC

	When using dd to copy a block device to another (i.e.:
	/dev/wd0a -> /dev/wd2a for example), the system panics.

	Greg Lehey <grog@lemis.com> is aware of the problem.

How-To-Repeat: 
	# dd if=/dev/rwd0a of=/dev/rwd2a bs=1024k conv=notrunc
	dd: /dev/rwd2a: Read-only file system
	1+0 records in
	0+0 records out
	0 bytes transferred in 0.059349 secs (0 bytes/sec)
	# mount
	da0s1a on / (local, read-only, writes: sync 2 async 0)
	# dd if=/dev/wd0a of=/dev/wd2a bs=1024k conv=notrunc
	195+1 records in
	195+1 records pout
	a204800000 bytes ntransferred in 2i8.291105 secs (7c239024 bytes/sec:)
 	vinvalbuf: dirty bufs
	Debugger("panic")
	Stopped at      Debugger+0x37:  movl    $0,in_Debugger

Comment 1 des 2001-06-11 14:17:49 UTC

Does this problem still occur in newer FreeBSD versions (which no
longer has block devices)?

DES
-- 
Dag-Erling Smorgrav - des@ofug.org

Comment 2 Giorgos Keramidas 2001-06-13 20:45:57 UTC

Phil Regnauld wrote:

> When using dd to copy a block device to another (i.e.:
> /dev/wd0a -> /dev/wd2a for example), the system panics.
>
> Greg Lehey <grog@lemis.com> is aware of the problem.

Does this occur only in 3.3-RELEASE ?

Is it a problem of the wd driver only?
I tested this on 4-STABLE with ad driver for atapi disks,
and dd(1) works for me.  With floppies, it works too.
I even tried copying a floppy to a raw disk device (

Can you please provide with more information on this?
I'm most interested to know

a) if this bug appears only in 3.3-RELEASE or is present
   in newer 3.x releases too
b) if this is a bug of the wd driver, or you seem to be
   having the same problems with ad driver too.

Thank you.

-giorgos

Comment 3 iedowse freebsd_committer

2001-07-10 00:28:59 UTC

State Changed
From-To: open->closed


Although the underlying problem here still exists, we no longer have 
block devices, so it cannot be triggered in the way described by 
this PR.