v.wales@Ucla-Security@sri-unix (11/12/82)
From: v.wales at Ucla-Security (Rich Wales) Date: 2 November 1982 2100-PST (Tuesday) I can recall having seen that same panic error at least once or twice, without any corresponding hardware errors. One possible candidate could be the test in "swstrategy" (in "sw.c") which sets B_ERROR if there are problems with the block number or byte count of a "struct buf" for swap space. Of course, these should never become invalid, but . . . . A more thorough perusal of the code might show other places where this panic could happen without a hardware problem on the disk. -- Rich Wales (Wales at UCLA-Security)
ucbvax:ARPAVAX:sam@sri-unix (11/13/82)
If you see a panic, "I/O error in push" without a printf from the device driver, it's almost certain that you ran out of space in the paging area. This is because of the check mentioned in sw.c that set B_ERROR when the requested block number is outside the limits of the paging area.
salkind (11/13/82)
If your disk is (becomes) write protected you will also get this panic.
mo@Lbl-Unix@sri-unix (11/20/82)
From: mo at Lbl-Unix (Mike O'Dell [system])
Date: 16 Nov 1982 13:18:14-PST
There is a tangentially-related bug in the disk drivers
for 4.1 - they don't do partial reads. If you want to
back-up an RM05 and say
dd if=/dev/rhp0c of=/dev/rhp2c bs=100b
(do 50Kbyte reads!)
you will discover the last transfer gets dropped as an error.
The size you give bs MUST integrally divide the size of the
disk partition. This is even more annoying when trying to copy
only one partition - some of them aren't even an integral
number of tracks!
The comparison in the hp disk driver says
if (base_address_of_transfer + size > MAX_BLOCK_OF_DISK) {
u.u_error = E_SCREWED;
return;
}
I would claim the raw disk should act like raw tape in that you should
in fact get what data it could give you and return the foreshortened
length. The current behavior causes me to have to use
dd if=/dev/rhp0c of=/dev/rhp2c bs=32b
and do track-at-a-time reads.
-Mike