Sorry, this got lost in the Ether somewhere, and has resurfaced, so I will answer!
On May 27, 2026, at 5:55 AM, Johnny Billquist <bqt%softjar.se@localhost> wrote:
I figure there are a handful of legit use cases for bad144 in NetBSD still:
- The vax port, obviously, but only with the really old drives. (VAX peeps please help me out here - is bad144 useful drives behind an MSCP-compliant controller?)
No. Any drive using MSCP do not use bad144. MSCP, just like SCSI, guarantees an error free disk. Any bad block mapping happens in the controller. *However*, other drives do use DEC STD 144. So that means RL, RM and RP drives (which are still supported on the VAX side). But with that said, bad144 have never (as far as I know) been supported/allowed on VAXen. Which annoys/perplex me to no end. The only platform that actually have disks using DEC STD 144 is one where bad144 is not built. How did that come about??? From the Makefile in /usr/src/usr.sbin/bad144: .if ${MACHINE_ARCH} == "alpha" || ${MACHINE_ARCH} == "i386" PROG= bad144 .endif So, only built for i386 and Alpha. :-(
Never understood why Alpha. i386 because 386BSD used it for bad block management on early MFM drives connected to WD1003 controllers.
Hilariously, the bad144(8) command has a bunch of #ifdef __vax__ in it :-) - hp300 port maybe (for HP-IB drives).
Do those really have a bad block list on the last track done the same way as DEC STD 144 specifies?
For some reason I thought there was some early version of BSD running on the hp300s that might have used it, and certainly the Utah-derived code had some vestigial bad144 handling in the hp300 port, but I can’t find any evidence that NetBSD ever used it. Sometimes, as humans, are memories are flawed.
- sun3 / sun4 (Xylogics controllers and SMD drives)
Same question.
Sun absolutely used bad144 on Xylogics-connected SMD drives, but they treated all the fields in the table as big-endian.
- i386 (ESDI, ST506, other ancient drive technologies that can plug into ISA or MCA)
Same question.
See above. bad144 should be reading the bad block list from the last track of a media, and I guess it then populates a list of bad blocks in the disk label, right?
So is there really a couplinng in here? Or isn't just bad144 one way of populating that bad block list in the disklabel. But the list as such needs to be somewhere where the disk driver can access it and handle it accordingly, no?
Well, the ATA code (which follows the lineage of the 386BSD stuff) consumes the bad144 table and produces a linear LBA array.
The Xylogics drivers that the sun3 and sparc ports use read the bad144 table into memory when the disk is probed (at the same time the disk label is consulted for the drive’s geometry parameters because SMD), and then the bad144 table is consulted if an error occurs during a transfer. As far as I can tell, this is basically how SunOS used the bad144 data as well. It’s actually a little annoying because it requires the sector to be **reliably bad**; if the bad sector is intermittent, you might read the original even if data has been moved to a re-mapped sector.
|