ATA / IDE drive details

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

lately I have been dusting off and testing a Cobalt RAQ2 I bought
a while ago.  Fan's been replaced (the old one spun only
intermittently and made noises...)  It has a

viaide0: VIA Technologies VT82C586 (Apollo VP) ATA33 controller

and an internal 40-pin connector for a normal 3.5" PATA drive.

It seems that this system is a bit finicky with what drives it
wants to cooperate fully with.  It came with a Quantum Fireball
4.3G drive, which works.  I've tried a couple of other spinning
drives (a 40G WD drive, a 750G drive), where the install goes OK,
but the system doesn't succeed in booting from them (for unknown
reasons).

I've also tried an SD-to-IDE adapter and also a 40-to-44-pin
adapter with both a laptop drive with spinning disk, and an mSATA
in a 44-pin adapter.  Some of these work better than others --
the mSATA variant downgrades pretty quickly to "no DMA" (while
reporting "lost interrupt"), while I had to do three or four
attempts with the laptop drive before the installation would
complete without errors.

During this process it's of course relevant to know what transfer
modes the drive and controller combination supports, and what's
used.  However, in the console log, I typically find

[   4.0899446] wd0 at atabus0 drive 0
[   4.0899446] wd0: <SAMSUNG HM160HC>
[   4.1006106] wd0: 149 GB, 310101 cyl, 16 head, 63 sec, 512 bytes/sect x 312581808 sectors

while if I log in and do "dmesg", more is revealed:

[     4.089945] wd0 at atabus0 drive 0
[     4.089945] wd0: <SAMSUNG HM160HC>
[     4.100611] wd0: drive supports 16-sector PIO transfers, LBA48 addressing
[     4.100611] wd0: 149 GB, 310101 cyl, 16 head, 63 sec, 512 bytes/sect x 312581808 sectors
[     4.109958] wd0: 32-bit data port
[     4.109958] wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
[     4.109958] wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA)

These extra lines are typically printed with "aprint_verbose()"
variants in sys/dev/ata/ata.c.  My question is basically: is
there a good reason why these extra lines are not instead printed
with the "aprint_normal()" variants?

I'm not sure there is a possibility to turn on verbose booting
with the cobalt, to get these also in the console log.  And then
the user needs to know that that's needed to get these "extra"
lines in the console log.

This certainly caught me by surprise, and confused me while
trying to understand if there's a pattern of what works and what
doesn't.

Regards,

- Håvard