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
