Subject: kern/3261: reading from /dev/cd0a returns incorrect data
To: None <gnats-bugs@gnats.netbsd.org>
From: Dave Huang <khym@bga.com>
List: netbsd-bugs
Date: 02/26/1997 03:26:28
>Number:         3261
>Category:       kern
>Synopsis:       reading from /dev/cd0a returns incorrect data
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 26 01:35:01 1997
>Last-Modified:
>Originator:     Dave Huang
>Organization:
Name: Dave Huang     |   Mammal, mammal / their names are called /
INet: khym@bga.com   |   they raise a paw / the bat, the cat /
FurryMUCK: Dahan     |   dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 21 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
>Release:        February 25, 1997
>Environment:
	
System: NetBSD host4.alterity.com 1.2C NetBSD 1.2C (SPIFF) #17: Tue Feb 25 23:41:12 CST 1997 khym@host4.alterity.com:/usr/src.local/sys/arch/i386/compile/SPIFF i386

and also

NetBSD host5.alterity.com 1.2C NetBSD 1.2C (GEDD) #211: Wed Feb 26 02:33:09 CST 1997     khym@host4.alterity.com:/usr/src.local/sys/arch/mac68k/compile/GEDD mac68k

>Description:
On 25 Feb 1997, Christoph Badura wrote:
> >However, "dd if=/dev/rcd0a bs=2k"
> >and "dd if=/dev/cd0a" don't return the same data. Even "dd if=/dev/cd0a
> >bs=2k" gives different data than reading from the raw device, which seems
> >rather strange to me...
> 
> That's not supposed to happen.  If you can't blame it on the NCR
> driver :-), I'd say, send in a PR.

Nope, not the ncr driver this time :) I see the same thing on my mac68k
system...

dd if=/dev/rcd0a bs=2k count=4 looks like this:

000000 45 52 02 00 00 13 e3 cc 00 00 00 00 00 00 00 00   ER..............
000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
*
000200 50 4d 00 00 00 00 00 02 00 00 00 01 00 00 00 02   PM..............
000210 4d 52 4b 53 00 00 00 00 00 00 00 00 00 00 00 00   MRKS............
000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
000230 41 70 70 6c 65 5f 70 61 72 74 69 74 69 6f 6e 5f   Apple_partition_
000240 6d 61 70 00 00 00 00 00 00 00 00 00 00 00 00 00   map.............
000250 00 00 00 00 00 00 00 02 00 00 00 13 00 00 00 00   ................
000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
*
000400 50 4d 00 00 00 00 00 02 00 00 00 09 00 13 e3 c3   PM..............
000410 54 4f 41 53 54 20 32 2e 35 20 50 61 72 74 69 74   TOAST 2.5 Partit
000420 69 6f 6e 00 00 00 00 00 00 00 00 00 00 00 00 00   ion.............
000430 41 70 70 6c 65 5f 48 46 53 00 00 00 00 00 00 00   Apple_HFS.......
000440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
000450 00 00 00 00 00 13 e3 c3 00 00 00 13 00 00 00 00   ................
000460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
*
001000

and dd if=/dev/cd0a bs=2k count=2 looks like this:

000000 45 52 02 00 00 13 e3 cc 00 00 00 00 00 00 00 00   ER..............
000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
*
000200 50 4d 00 00 00 00 00 02 00 00 00 01 00 00 00 02   PM..............
000210 4d 52 4b 53 00 00 00 00 00 00 00 00 00 00 00 00   MRKS............
000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
000230 41 70 70 6c 65 5f 70 61 72 74 69 74 69 6f 6e 5f   Apple_partition_
000240 6d 61 70 00 00 00 00 00 00 00 00 00 00 00 00 00   map.............
000250 00 00 00 00 00 00 00 02 00 00 00 13 00 00 00 00   ................
000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
*
000400 50 4d 00 00 00 00 00 02 00 00 00 09 00 13 e3 c3   PM..............
000410 54 4f 41 53 54 20 32 2e 35 20 50 61 72 74 69 74   TOAST 2.5 Partit
000420 69 6f 6e 00 00 00 00 00 00 00 00 00 00 00 00 00   ion.............
000430 41 70 70 6c 65 5f 48 46 53 00 00 00 00 00 00 00   Apple_HFS.......
000440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
000450 00 00 00 00 00 13 e3 c3 00 00 00 13 00 00 00 00   ................
000460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
*
000800 45 52 02 00 00 13 e3 cc 00 00 00 00 00 00 00 00   ER..............
000810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
*
000a00 50 4d 00 00 00 00 00 02 00 00 00 01 00 00 00 02   PM..............
000a10 4d 52 4b 53 00 00 00 00 00 00 00 00 00 00 00 00   MRKS............
000a20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
000a30 41 70 70 6c 65 5f 70 61 72 74 69 74 69 6f 6e 5f   Apple_partition_
000a40 6d 61 70 00 00 00 00 00 00 00 00 00 00 00 00 00   map.............
000a50 00 00 00 00 00 00 00 02 00 00 00 13 00 00 00 00   ................
000a60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
*
000c00 50 4d 00 00 00 00 00 02 00 00 00 09 00 13 e3 c3   PM..............
000c10 54 4f 41 53 54 20 32 2e 35 20 50 61 72 74 69 74   TOAST 2.5 Partit
000c20 69 6f 6e 00 00 00 00 00 00 00 00 00 00 00 00 00   ion.............
000c30 41 70 70 6c 65 5f 48 46 53 00 00 00 00 00 00 00   Apple_HFS.......
000c40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
000c50 00 00 00 00 00 13 e3 c3 00 00 00 13 00 00 00 00   ................
000c60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
*
001000

After looking at more output from the dd, it seems like each sector of the
CD is being output four times. :( Perhaps the block I/O routines have
trouble with devices that have a block size other than 512 bytes?

>How-To-Repeat:

% dd if=/dev/rcd0a of=raw bs=2k count=4
4+0 records in
4+0 records out
8192 bytes transferred in 1 secs (8192 bytes/sec)
% dd if=/dev/cd0a of=block bs=2k count=4
4+0 records in
4+0 records out
8192 bytes transferred in 1 secs (8192 bytes/sec)
% cmp raw block
raw block differ: char 2049, line 1

>Fix:
	
>Audit-Trail:
>Unformatted: